Hoppscotch

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Transcript

I’m super interested in talking to Liyas Thomas, who amongst other things is the Founder of a cool API application. I’ll let him talk about it as we go. Welcome, Liyas. Thank you so much for joining us.

Thank you. Thanks for the lovely intro. It’s nice to be here.

{{divider}}

Do you want to give us a bit of a background of how you started coding and how you came about starting a super popular project on GitHub?

My name is Liyas Thomas. I live in India. My profession is I’m a product engineer. My background is in engineering and tech. I’ve been a developer for many years. After my graduation, in my first ever job, I was struggling with a certain situation while dealing with APIs in my workplace. The project Hoppscotch started in a three-hour window every night. That is the project that later became an API ecosystem for testing, sharing, saving and a lot of other stuff.

It’s been years since I started working on Hoppscotch. My background is very typical. I started working when I was 12 or 13 in school. My first development title is in Java android and native apps but later I fell in love with websites and web apps especially with the JavaScript Ecosystem. I pivoted to making web applications. It’s been years since being a web developer. I was previously a product engineer at Buy Me A Coffee but for now, I’ve been fully working on Hoppscotch.

{{divider}}

One of the most common things that I’ve experienced from talking to a bunch of different founders, without exception, they’ve started working on a project because it was something that they needed quite often in there as an aid to their professional life. That’s almost everyone I’ve spoken to. I guess that’s the same for you. You were trying to interface with some APIs and you couldn’t find a tool that worked for you. Is that fair to say?

That’s exactly what it’s like. I can talk a little bit about that statement because the ideal thing for Hoppscotch is to have an alternative to the existing development tools. There are a lot of alternatives, which have their own advantages. There are GUIs that are serialized with everything that works in the same space. In my own space, when I was dealing with APIs, I had it easy with the most basic specifications like 2 GB of RAM and a ten-year-old AMD processor with me. I’ve had that project one at a time. On that night when I was trying to test a bunch of it, there were 100-plus employees with me on that very day. My mindset was I was supposed to test the APIs and bind it to the UI.

I tried to download this common and most popular application which is an enterprise application and millions of developers are using it but my poor ten-year-old PC couldn’t afford to run another electronic because I knew how electronics work. I knew how it renders a web application package within headless phones. I knew how much RAM or memory consumption it might take from my laptop. After downloading that, I tried to install and open the application but it crashed the system. I was so frustrated. I decided that I need a solution that works on the web. Something that I can operate from the browser itself because I don’t want to switch back and forth between my editor and browser window.

I wrote this simple one-page HTML file, which allowed me to make it rootless directly from the browser. That was it. It had a couple of inputs to answer the buttons and the first hour lets you fire rootless from your browser window. I open source that very basic entity. It was not polished and not up to the month but they probably know in the GitHub pages. The next day when I woke up, I woke up to this 100-plus notifications from GitHub to my profile. By the end of the week, I had almost 5,000-plus downloads using that first MVP that I made in 2 to 3 hours.

{{divider}}

Of everyone I’ve spoken to, you’re at the top of the leaderboard in terms of out-of-the-gate adoption and impact. It took us maybe three years to hit a thousand stars and you got three weeks. You had no idea that it might happen, right?

At first, I did not have any idea what’s happening. Why everybody’s sharing the project with their peers and why we are getting all this attention at first. Later, I realized that I was so privileged and lucky to find about this community of developers and engineers who wish they had such a tool but they never did. They always wished they had a tool which can fire directly from the browser but all they had at that point in time was binary bills for different operating systems. They had their own disadvantages like conception. It was a hectic task. The first MVP got a lot of attraction in the initial days. We had more than twenty contributors in the first month for 100 developers.

There were a lot of bugs too. Most of the functionalities, which the developers might expect from such a tool, were missing on the daily dates. The open source communities have been wonderful. They started computing the way they raised issue tickets. They passed a lot of sales. It’s been years. Now we have crossed 500,000-plus users. That’s somewhere 25,000 plus monthly recurring usage. It’s been months since I switched to Hoppscotch full-time because I used to be a full-time employee in another company. If you think about it, it’s a quite great.

{{divider}}

When you initially pushed that first version to GitHub, did you then market that project anywhere or did you send this to friends?

There are a couple of things that I intentionally did. I chatted with my friends and peers, out of which one was, I wrote a blog on my DEV.to profile. At that time, I had 200-plus followers on DEV. That post that I wrote on that very night got viral. It had more than 10,000-plus page views at the moment. I gained more than 11,000-plus followers on DEV. That post is something that I guess is the most significant impact that we had on our early days.

I tried to share it with my friends on developer forums in Reddit, in subreddits, on Twitter and the Slack channels that I’ve had also. One thing that I find about getting this attraction in our early days is that developers started sharing it with their friends and peers in closed communities. That brought up this compound effect on getting popular. That’s how it all happened.

{{divider}}

It’s a very modern story. A lot of the people I’ve been speaking to started their projects many years ago. It’s taken them that long to get as many stars as you have. It sounds like it’s a modern story in terms of you were naturally using distribution channels that didn’t exist many years ago like small open source code and communities like DEV.to . It’s interesting how quickly you can amplify and then other members of your community can amplify that signal.

I support that idea because one thing that I find about how to promote your open source project or how to help with that software distribution part. It’s a tricky thing because there are thousands of open source repositories created per day. Most of them are in the same space either the EPA or the analytics, plus there is a lot of software distributed every single day. If you want to stand out from the crowd, you have to make some tweaks like chatting or talking about your product where the developers hang out. You have to find the places where your potential audience will hang out. Forums like DEV.to or Hashnode, all these forums are the places where potential engineers and developers are hanging out. I thought sharing about our project on that basis will be best when compared to other sources.

{{divider}}

You had a full-time job at this point. Did you feel overwhelmed in any way? Did it start feeling like it was out of control in terms of people requesting features? You were trying to deal with serving all those copies of Hoppscotch to browsers and stuff. Did you get underwater at any point?

Yes. It’s a place for every officer and developer that are out there with us. On our initial days, doing this style where we were getting more than 50-plus feature requests every week. For months, it was requested. There was a lot of time where I had to spend my entire night reviewing the pull requests, replying to issues and convincing users. There was no documentation for the verdict on our initial days. I had to manually test back to every user who raised their concern. There were a lot of tough times but the project is being built and the community engagement is pretty good because we don’t have a large count of existing issues.

Our current offer is less than 40. We spent a lot of time fixing these and making the platform welcoming for web developers. Especially in our early days, being an API testing tool that works completely on the web interface, there were some technical difficulties as well like the cause issues and some technical steps that don’t play well on a browser. We were forced to come up with some other supporting software like a browser extension like an interested ad and a proxy server.

The ecosystem grew with the help of the open source community. They gave the feedback, contributed to the source code and more than 80-plus feature requests are either caused by commenting or requested from the community. We have to do this to be in the space and have a loving and supportive community.

{{divider}}

Did it come quite naturally in terms of delegating work to the people who were helping you or was that something that you felt like you found you had to do a lot of work on to get to that point? Your GitHub repository is interesting. You got a ton of stars. You’ve got a very small number of open issues that were labeled well. You’ve only got six pull requests. It’s interesting because it reflects the application as well. It’s the tiniest, neatest, most well-organized repository.

{{divider}}

The interface to the application can be a very complicated thing is super clean and pared down. It looks simple. I can never use Postman. I stopped using it because every time I opened it, I became more confused with the user interface. They published features so quickly. I couldn’t keep up with it and I had to stop using it. Going back to the community, was that something that fell into place quite naturally?

I would say yes because we haven’t spent a single penny on anything, which is not organic. Everything related to Hoppscotch’s project is organic to the site like the community engagement and the pull request, everybody who has contributed. There are several things that we initially did to make it as easy as possible. Most of our features are outlined. The targeted audience, which are developers and engineers, knew at least something about the application. They know what they have to expect from such an application.

There is no delay of doing opening the app. You can start with Hoppscotch within the first five seconds of offloading the applications because they know how Salesforce in an API platform as a CSS. On the contributing part or the engagement with the community, we have a policy which is to make everything as easy as possible for the contributors to start up with contributing to Hoppscotch. One of the most significant things that we did is if someone asks for a feature or a bug that apparently has been put up in our issues ticket, we are seeing a particular request or an issue to multiple persons. It will be a micro team of 3 or 4.

Those four people might be one from the US or one from the UK or one from China. It’s a group of developers working from around the world contributing to a single feature or a bug feature. How it handles because if you think about it, it’s quite interesting because everybody lives in different time zones. Everybody has their own skillsets. If someone likes to work on the jobs, they can do that part and let others work on the remaining stuff. If someone likes to write the test for that particular feature, they can write the tests and contribute to that pull request. It will be drafted.

Someone from our code team or myself will contribute to the code logic of that feature. By the end of that day, one thing pull request that has been contributed by 6 or 7 guys from around the world working in multiple different time zones. A pull request is quite interesting to me because they had contributed to the sections that they are good with. If someone likes to do the frontend, they start off beautifully. At the end of the day, it gets most of the prediction. Everything about Hoppscotch is developing, we always have that feedback from the community. Not just as the feedback but also the participation of the community to make every single feature. This is the most important reason why we have a slim easy to use and user-friendly application.

{{divider}}

I hadn’t thought about the idea that if you’re paying for traffic to your GitHub repository, you get a different mix of users that then potentially are raising issues or they’re going to have a different set of behaviors. Who wants and needs comparing to if it’s all coming organically, which is what’s happened with you guys. The difference architecturally between Hoppscotch and Postman is that you can go to the Hoppscotch webpage and you’re straight into the application. That’s like a static webpage. If I execute a web request to test an API that’s happening from my browser?

We wanted a solution that works completely, 100%. We don’t take anything out of your browser if you clear the cookies. The default mode is 100% static and that’s HTML base that has been bundled to work completely authentic one. There is this other mode where if you sign in or log in with the provider like GitHub or Google or even using your email, we will essentially sync your data, including history collections or anything that you want to sync. You can explicitly turn it off if you want and we will sync it with our cloud so that you can start from where you left off in another device, mobile phone or tablet. The default mode is 100% static. Nothing leaves your browser.

{{divider}}

That makes it easy to hack around with the projects. You don’t have to set up a service stack or deploy a bunch of stuff or web servers. You’re running a local webpage basically.

That’s correct. You can throw on the video repository from a command and you get the entire app which can be shared within your premise or internet servers. Also, you can build it or compose it for yourself. That’s possible.

{{divider}}

It’s such an elegant architecture for what it’s achieving. It’s interesting as well that it came out of your requirement of not using another quarter of a gig of RAM on your desktop.

That was the plan.

{{divider}}

Another thing I wanted to talk about was the overall design and user interface. It’s going to be up there as one of the most beautiful open source products that I’ve seen. Even the documentation looks better than a whole lot of heavily funded commercial applications. How did that come about? Was that something that you wanted?

I created the entire interface for Hoppscotch. I love designing these interfaces. I fell in love with the web application. I’m curious about how web apps work. I custom-made all the components that we use in our Hoppscotch platform. One funny thing about Hoppscotch is that when I thought about creating an application, I was so keen to take a framework that I had never been used to.

I used the Next.js framework to build Hoppscotch’s ecosystem. That was the first time I used the js for an application because I wanted to do learn how that framework works. I used to be a React developer but Hoppscotch is my first ever new application. All the UI components are custom-made and custom-style. Altogether, the platform looks very simple, modern, easy to use and lightweight.

{{divider}}

The typography and layout of the application are amazing. Everything is perfectly positioned. It’s so nice. For an application, it’s easy to have an incredibly complicated user interface because some of the deeper aspects of crafting a web request can get super complicated. Dozens of different options and obscure parameters and things like that. I love Postman. I don’t want to talk down on it too much. They’ve done a great job and they’ve got a good business behind it but I stopped using it because it got too complicated.

{{divider}}

I started using Core. For those of you who don’t know, it’s a great native desktop application on macOS. I don’t use 90% of the things that it can do. One question I have was for an interface that could easily become super complicated and noisy, have you had a problem with people creating pull requests that needlessly add noise to the interface? How did you go about balancing those people creating those pull requests with what you’ve achieved, which is to have this clean product?

For such a project which has engagement with the community, there are a lot of chances of getting too much noise. Not just in the pull request but also for the feature request or the roadmap. We have a small framework within our company in which we always think about how to minimize the complexity of the problem. We even get feedback. We will get continuous feedback from our community through different channels. We have a public Discord, Telegram group and Slack channel. When a problem comes up, we get multiple solutions from the community.

There will be this engagement from the coding as well. We evaluate all the possible solutions and try to define and decide the simplest solution first. One advantage of this framework is that you can do at least 80% assured that nothing noisy goes into the application, which will become a bug if you keep on doing that for more than 1 or 2 years. On every decision that we take, not just about the pull requests or the features that we develop, we always find stuff the simplest and the clean way of performing it and that will eventually get to the platform. We refactor our entire application once every 2 or 3 months. We spend the cycle to have two weeks to refactor the application with the latest index, updating the differences and keeping it as efficient as possible. Making a project is as important as saving the project.

{{divider}}

One of the things that I found when I was researching your projects, it’s a super interesting thing where if you go to the website, there is no website. It’s just an application, which is super-efficient. Do you have plans behind it as a commercial business? How are you thinking about building it as a long-term project?

One of the things that I want and it’s not just a personal choice but also what the community need is we want our users to get started with the application within the first five seconds of offloading the page. There was no landing page for Hoppscotch throughout the past years. The first MVP didn’t have a landing page and even now, we don’t have a landing page. If you think about it, it’s quite interesting because our users are mostly developers and engineers and they have a little bit idea of what they might have to expect from such a tool. For me, it didn’t make any sense to have a landing page with the CTA to our application and users have to sign in to use the application. It didn’t even make sense to file an API.

We intentionally removed the landing page and let the users use the app within the first five seconds. Again, if you consider the project in a business or in a much more serious space, we’ll be having a landing page in the future. I can promise you that there will be two domains because we have Hoppscotch.io and Hoppscotch.com . The users who want to use the app, can go to Hoppscotch.io which is the default platform base.

If you want the documentation, blogs or upcoming sales, we’ll be directing the users to Hoppscotch.com , our top-level domain, which is a work-in-progress and will be launched in the near future. This is one of the sales that we haven’t planned to make the application and to do these much more enterprise-level users in a commissioned way of presenting the application so that we can build a lot of plans and other projects in Hoppscotch’s ecosystem.

{{divider}}

Is that one of your plans as an organization to start offering paid features to larger organizations?

Hoppscotch is tailored for individual users and for smaller teams of, let’s say, fifteen members. We will be having multiple plans offered. There will be a plan for enterprises or organizations where the employees are more than 500. We’ll be having all the enterprise-ready features like a small much higher enrollment sharing, shared collections, EPA marking and all the features that might recur for an enterprise organization in the near future. Hoppscotch for enterprise will be an enterprise or the application of what we have but it will be a completely isolated application only for those who need that application.

At the moment, we have a common condition. It’s a public Hoppscotch repository and it’s tailored for individual users and for small businesses. Between these individual users and enterprise organizations, we will be also having Hoppscotch for teams which is an intermediate plan with the most essential features needed for companies, startups or development enterprises. Those are the audience that we are targeting. There will be multiple plans for enterprises, small businesses and individuals. There will be general reviews with all the features with the capacity limit also. That’s our roadmap.

{{divider}}

One of the things that would worry me if I was hosting this is the security aspects of when you’re storing API tokens or if you’re storing your collections in the cloud. How’d you go about managing that because you’re naturally by virtue of the type of product it is going to be coming into contact with some super sensitive strings of data?

That’s a very important concern for all the engineers and developers who are dealing with API. The API is a sensitive collection of data including your tokens, authentication credentials and almost every data that you’re handling in API because this is very sensitive. This is exactly why we wanted an application whose source code is open and anybody can take a look at it. What we are dealing with in the API is how we are sending the request, what is being saved and omitted? Where is it being saved? All the experts on the application flow are 100% transparent. Therefore, ease in the checkup.

At Hoppscotch, we have multiple modes. In the default mode, if the user is not signed in, the entire application will be a 100% static website opening in your browser window. Every request that you make is generated from your browser and directly sent to the API endpoint that you mentioned. This is the simplest operation at Hoppscotch. At this point, nothing leaves from your browser except the request that is being synced to the endpoint.

For those users who would love to have this feature of shared sync state within multiple devices, they can sign in with an authentication provider. We have Google, KickHub and by signing in with your email, you can have a synced state in which users can choose what to sync and what not to sync. If you go to the profile page, you can see synchronization, which includes history, collections and environments. The data, including the API tokens and everything, will be saved to either of these three sections. One is the history where you make the request and it will be saved in the history.

The collections where you sell a group of similar APIs through folders and subfolders and collections. There will be this environment, which might differ from staging to production, testing or intermediate level of development. These three can be synced to our cloud for that we have a private DCP engine and users can choose not to sync with them so that the current state will be the only thing that has been synced.

In a commercial aspect of the project, we will have a community which can be brought by a license key so that can be hosted within the premise of the organization. It can be adopted image, local system, internet server or anything that can host a webpage. Organizations can do that. They can get the source code from the GitHub repository or spin up our Docker image and they can host it within the premise for free. If you do this, nothing ever goes out of the hosted machine. Everything stays intact and you can be 100% assured of the sensitive data and the privacy.

{{divider}}

In terms of marketing the project and products, are you consciously doing that a lot? How much time are you spending on that side of things?

I still write code for at least 5 to 6 hours a day. That remaining time, I will be talking about the product to my peers and reading the full repairs. It is applying to our customer chatbot and issues that have been reported in our various public forums and GitHub repositories. In terms of marketing and the entire software distribution, everything happens organically at Hoppscotch. The entire reach or getting the word off of mouth and everything used to happen organically. We don’t have a designated team to do that. Me being the build hacker, the CEO or everything related to marketing, we share the story of making Hoppscotch.

The idea behind Hoppscotch to our developer communities, our friends and that’s how it has been going and that is at least is phenomenal. Since everything happens organically, developers or engineers who used Hoppscotch once, they chatted with peers and it’s a comforting thing by the end of the day. Since things are getting serious, we might have a Developer Relations Officer who knows how to handle these things much better than me in the near future if everything goes as planned.

{{divider}}

Writing codes six hours a day, that’s living the dream. I’m fairly jealous at this point. One question I also had was about the license. How did do you decide on your MIT license?

I didn’t have any homework on choosing the license.

{{divider}}

You get taught how to write code and how to encapsulate classes but I can’t read legal documents. Did it feel like a natural one to choose?

The funny thing about choosing a license is that I used to be an office contributor for more than five years. Hoppscotch is not the first-ever side project that I have made. There was a decent list, other projects that I’ve made. All of them are MIT licensed, which it’s strictly apprehensive. It was like a routine for me to have a nonrestrictive license for all this. I make because I want everyone to use the project because that was a solution that I either made or come up with because I was having an issue in the first place either in my workplace or in my life.

I choose the MIT license or Hoppscotch on the first day and we haven’t changed a little bit. If you think about it, there is always this tricky part. There can be another project that can or another name. You can expect another project that might get published but the way I was thinking about is that you can copy the code but you guys can’t copy the community behind the idea. This is our strongest point because the idea or vision behind the project is too much important than the source code that we wrote to make that solution.

We have a community of engineers and developers or our users who believe in that idea and are very supportive of what we are doing. There will be a lot of commentators, not just in offices but also in property sales but the community stays. That’s the best thing about open source. We have the audience with us and they support us. I don’t have intentions regarding that. They always use this freedom for the users to add their own little dates because, at Hoppscotch, more than 45% of our users are from Asia Pacific regions.

That includes users from China, Singapore, even from an adequate amount of users from India. There are more than 50% of users but on such geographical locations, they have locked off restrictions on using a property service like at China or any geographical locations, which has restrictions on using property services. They tend to use open source projects and they like to have them hosted within their premise. This is only possible if the project has a lesser restriction license. This always helped us to reach a lot of geographical locations apart from the way it works. It always has been a good thing for most of us to have an MIT license with us.

{{divider}}

I wonder if your architecture and whatnot if it becomes more usable or interesting for developers in China or places where it’s quite often a lot of services and applications are restricted or don’t work. That’s an interesting aspect as well. We’re coming up on the hour here. Have you got any features or news or community members that you want to mention or make the readers aware of?

I would like to mention our CTO, our Hoppscotch head on everything related to the backend and the Head Prospector. His name is Andrew Bastin. He’s an undergrad student. He is studying in Canada. He is the first-ever external contributor to the project and became my Cofounder and the CTO role. He is one of the guys who I owe most of the technical background and all these too. There are these 550-plus other contributors who have suffered at the project throughout the years. We load Hoppscotch for teams MVP where users can create teams and share collections. They can invite their team members, assign roles like admin, editor, viewer and they will have respective roles within the shared collection.

This is the foundation of IPR we are expecting to do where most of the prominent features will be tailored for Hoppscotch for teams. At the end of the day, it will be an isolated edition, which will have a subscription plan tailored for smaller startups or companies. There will be a free generous plan. This is the direction of our company and what we are trying to accomplish. This plays well along with our vision of having an ecosystem of tools that will allow developers to test, save and share APIs in their workflow.

We will be having multiple sections within the ecosystem that will tell us almost every API data manual cycle not testing and the conception that goes with the designing and also the development, testing, sharing, concept. We will be always trying to get feedback from the community on what should be the next switches. That’s how our mission works. That’s how we are working at Hoppscotch. That’s about it. Stay tuned for the upcoming features.

{{divider}}

Congratulations on where you’ve got yourself to. It’s great. I’m looking forward to you guys having an actual homepage because I’m sure it will look amazing. I can’t wait for that. Thanks for your time, Liyas. Good luck in the future.

Thank you, Ben.

{{divider}}

Have a good day.