🤝 Sponsor

This space is reserved for sponsors that support us to keep the newsletter going! Want to support Console? Send us a note at osh@codesee.io

🏗️ Projects

Browse through open source projects on OpenSourceHub.io, add your project to get more exposure and connect with other maintainers and contributors!

shap-e

Generate 3D objects conditioned on text or images.

language: Python stars: 7864 last commit: 3 days
repo: github.com/openai/shap-e

OpenRCT2

OpenRCT2 is a simulation game where you design and build an amusement park while balancing profit, thrills, and happy guests.

language: C++ stars: 11795 last commit: 5 days
repo: github.com/OpenRCT2/OpenRCT2
site: openrct2.io

Mockoon

Mockoon is the easiest and quickest way to run mock APIs locally. No remote deployment, no account required, open source.

language: TypeScript stars: 4968 last commit: 3 days
repo: github.com/mockoon/mockoon
site: mockoon.com

Join thousands of other open-source enthusiasts and developers in the Open Source Hub Discord server to continue the discussion on the projects in this week's email!

🎙️ Interview with Guillaume of Mockoon - an open source API Mocking tool

Hey Guillaume! Thanks for joining us! Let us start with your background.

Hi, My name is Guillaume. I am from France, currently living in Luxembourg. 

I am a legal practitioner turned web developer eight years ago. I switched careers after working as an in-house counsel for several years. Long story short, I am self-taught and started coding in high school with C++. I spent most of my free time coding, a bit too much, I would say. It was not only a passion but an obsession! 

And eight years ago, I felt it was time to choose to pursue my career in the legal field, glancing at the development side with envy, or make a bet and try to work as a developer and reclaim my free time. 

After switching careers, I worked at various companies in Luxembourg, mainly in the financial industry. 

I work with Javascript most of the time, front-end and back-end. I use Typescript everywhere, and Angular is my favorite framework.

Who or what are your biggest influences as a developer?

For being dedicated, switching careers in my 30s, never stopping learning, I would say my parents.

What's an opinion you have that most people don't agree with?

I want my stack to be boring and stable. I don’t want to waste hours every day updating dependencies, rewriting half of the code, and debugging cryptic errors due to breaking changes. 

We need to understand that we use tools that serve a higher purpose: create a business, for example.

What’s your most controversial programming opinion?

I am not sure I have one. Maybe that unit tests are completely useless.

I will trade end-to-end or integration tests for your unit tests any day.

What is your favorite software tool?

VS Code I guess. It’s highly customizable, and it’s working really well. 

What are you currently learning?

Writing efficient ChatGPT prompts and NestJS. I am using these to build Mockoon’s next features.

Why was Mockoon started?

Out of a personal need more than five years ago. I worked in a front-end team, and the API wasn’t ready. I tried some API mocking tools that I didn’t like. Too cumbersome and not powerful enough. 

So, I started working on Mockoon in August 2017. I published an MVP in October. 

I guess that being a developer, I also really wanted a side project to spend my nights on! 

How does Mockoon work?

Mockoon is mainly a desktop application built with Electron. It uses Angular, which is my framework of choice. I know it perfectly and can be very productive. 

There is also a CLI application, a Node.js package built with Oclif.

What do you think are the biggest challenges facing developers today in terms of working with APIs, and how does Mockoon address those challenges?

Mockoon's specialty is API mocking. 

From where I stand, working with APIs, both internal or third-parties, can be a hassle especially during development. Usually you have to create accounts, maybe pay, provision tokens, etc. The API may not have a test mode. 

For internal APIs there are other challenges, like they may not be ready yet. It creates a strong dependency between the front-end and back-end teams.

So, most developers need to mock APIs at a very early stage of the development.

Many tools are not considering this and only offers API mocking capabilities as an after-thought. It's often cumbersome or not powerful enough to cover all your use cases. 

Our promise is to let you mock anything anywhere as quickly and easily as possible. 

The result is an application where you can mock any endpoint in less than a minute and start working.

Where did the name for Mockoon come from?

I wanted a name that is cool, unique, and non-descriptive while still reminding users of API mocking, with a .com domain available. Many combinations were already taken, like Mockaroo (great name, by the way). I was lucky enough to find an available .com for Mockoon, the mocking raccoon. 🦝

Combined with the “eyes” logo, it’s the perfect memorable brand. 

Are there any overarching goals of Mockoon that drive design or implementation? If so, what trade-offs have been made in Mockoon as a consequence of these goals?

The main goal is to keep things simple and easy to use. Sometimes, we don’t implement features on purpose. To keep Mockoon’s scope focused and coherent. 

It is a real challenge as more and more users request features. 

I really like GitHub’s approach of implementing features that don’t clutter the UI or get in your way. They only get triggered when you need them. For example, GitHub will suggest choosing a license only when you create a LICENSE.md file. 

I would really like to take this path with Mockoon. Let’s call these silent features.

What is the most challenging problem that’s been solved in Mockoon, so far (code links encouraged)?

The biggest challenge is distributing the app for multiple operating systems and architectures (x86_64, Arm64, etc.) and fixing the bugs that come with it: app icon not shown under Ubuntu, application not closing properly on Apple Silicon, etc

These kinds of things. 

To overcome this, I have several VM to test the binaries, and I added some automated tests that run on each commit using the packaged binaries.

I also rely on the community to test patches on their machines, especially for Apple Silicon machines, which I don’t own. (I am a Windows developer, come after me 🙂)

How does Mockoon integrate with other tools and technologies commonly used by developers, such as CI/CD pipelines or testing frameworks?

Mockoon offers a CLI that can run a Mockoon configuration file anywhere an NPM package can be installed and run. 

How does Mockoon differ from other API mocking tools, and what makes it unique?

Mockoon can be used for API design but focuses on API mocking. It’s also a versatile tool that you can use for prototyping, teaching, or simulating advanced use cases to be used in continuous integration workflows. A bit like a Swiss army knife API mocking tool!

What was the most surprising thing you learned while working on Mockoon?

A lot of developers ignore that they could benefit from API mocking. There is always a use case where you can use this technique. 

In one place I worked at, we used it to intercept all requests from the application and add a specific header that could normally only be added by using a proxy to which you had to log in, select options, click on buttons, etc. 

With Mockoon, it was done in 30 seconds. Way less annoying and not less secure. Maybe not your typical use case but definitely a time saver. 

What is your typical approach to debugging issues filed in the Mockoon repo?

Often, I have gut feelings telling me where the problem is coming from, even without reproducing steps. If not, I usually request as much information as possible to be able to reproduce the issue. 

Sometimes, some strange edge cases are seemingly impossible to reproduce. I try to help the user as much as possible to find a workaround. It can be frustrating, but there are many moving parts and interactions with the different operating systems, and sometimes the bug wins.

What is the release process like for Mockoon?

This process is automated for the most part. Each commit is tested in development mode, and some tests run against the packaged application. 

When releasing the application, binaries are built and signed automatically in a GiHub workflow. It saves me a lot of time. 

Then, the distribution is mostly a manual process. It's the last step that is not automated. 

It includes writing the changelog, publishing the application to the Microsoft or Snap store, opening a pull request for brew, etc. 

I don’t like tools that write changelogs automatically from commit messages. I prefer my changelogs to be a bit more user friendly, with screenshots, small announcements, etc. A bit like VS Code. 

For the CLI, the process is fully automated. New versions are directly published on NPM by the GitHub workflow. 

Is Mockoon intended to eventually be monetized if it isn’t monetized already? If so, how?

Monetization was not the first objective. It was a side project at the beginning. But its popularity made me rethink what could be the outcome for me, and I quit my job in 2021 to work full-time on Mockoon. Fast forward two years, I am getting sponsoring and enterprise support contracts, and I will release a small cloud offering soon. 

If everything goes well, I think it will be a win-win. I can continue working on the project and keep it open-source while making a living out of it. 

How did Mockoon get popular? Where is it being used?

After building an MVP for roughly three months in 2017, I posted the application link on the traditional websites: Hacker News, Reddit, ProductHunt. The feedback was overwhelmingly positive, so I kept working on it. During the first years, I guess it grew thanks to word of mouth mostly and a bit of SEO. But I wasn’t writing anything myself. The last two years, I started writing much more. More documentation, some tutorials, articles, etc. Today, SEO is bringing most of the traffic. I try to post on social networks, but it’s time consuming for a below average return. I guess you have to post a lot to create an audience, but I am not very good at it!

What are you most proud of?

I am proud that I built something that thousands of people use every day. Also proud that I kept working on it for five years. It wasn’t always easy. 

I am also humbled that so many people are using my tools. I didn’t expect that, and I hope I serve them the best possible. 

Something that I am really proud of. Mockoon was recently selected by GitHub to be part of their first Accelerator cohort. It was a real surprise!

It's a huge step forward. 

Have you ever experienced burnout? How did you deal with it?

Yes, in late 2020, trying to juggle my family, my job, and working on the project during the evenings. I put too much pressure on myself, trying to answer support requests as soon as possible, release as many features as possible, etc. 

I dealt with it by making a choice. Either reduce the time I worked on the project or quit my job. As the project was growing, I resigned some months later. My family was also very supportive.

I learned to stop caring too much. I still strive to give the best support I can or implement the features in the best way. But I realized that there was no real emergency. It’s a free tool. People were fine before. They will still be fine and can wait a bit. It also made me realize how toxic the traditional work environment can be, with its fake deadlines, pressure, etc. 

If you plan to continue developing Mockoon, where do you see the project heading next?

Getting more features, the ones that help people deploy their mock everywhere. Like managing remote CLI instances. And also the ones that broaden the appeal to people teaching APIs in general or needing prototyping tools. 

I will also release a small cloud offering. It is critical this year to make the project sustainable, alongside getting more sponsors. 

What motivates you to continue contributing to Mockoon?

The perspective of being able to work on an open-source project while being paid for it (through sponsoring or paid services). It would be a life-changing event for me. 

Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!

Leave a comment

Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at osh@codesee.io or mention us @ConsoleWeekly!