Hi readers 👋, welcoming you back to the "Appwrite OSS Fund" series, where we celebrate open-source maintainers. 🎉
🤔 What Is OSS Fund?
On the 4th of May, the Appwrite team launched the OSS Fund, an initiative to support open-source project maintainers. Being an open-source company, we wanted to give back to the community and help as many people as we can.
The OSS Fund is an initiative that is very close to our heart.
Hear what our Founder and CEO has to say - The Appwrite Story:
Announcing the Appwrite OSS Fund - Appwrite
Appwrite provides web and mobile developers with a set of easy-to-use and integrate REST APIs to manage their core backend needs.
appwrite.io
📢 Announcing The Twelfth Project
After careful considerations from the committee we are thrilled to announce the twelfth project:
Appwrite@appwrite
📢 Announcing the 12th #OSS Fund Sponsored Project 📢
We are excited to sponsor @ApiMocking 🥳
Looking for API mocking tools? mswjs.io to the rescue!
Tag a maintainer who can benefit from this fund, application link in the next tweet 👇10:38 AM - 16 Jan 2023
🤔 What Is Mock Service Worker?
Mock Service Worker (or MSW, short) is an API mocking library for browser and Node.js. It intercepts requests your app makes, and allows you to respond to them with mocks. Sounds like any other API mocking library out there, and yet there’s a distinct difference. See, MSW doesn’t alter your application. It doesn’t stub fetch, doesn’t introduce configurations or adapters, and instead allows your app to work the same way it works in production. That’s made possible because MSW uses the Service Worker API to intercept outgoing traffic on the network level—after it’s left the app. In Node.js, it extends standard Node API classes instead of stubbing them, aiming for less changes to your application as well.
On top of that, MSW is environment- and tool-agnostic. You can use it with anything, really. React, Angular, Vue, Next, Gatsby, Remix, Cypress, Playwright, anything. That’s not even the best part. The best part is that you can reuse mock definitions with MSW across all those tools, again, without any configs, plugins, or adapters. It’s simply a cost-efficient investment into your testing and development workflow, and it has already become a de-facto goto choice for countless companies around the world.
🤝 Meet The Maintainer
Artem, who is a software engineer from Ukraine is the creator of Mock Service Worker. He has been interested in programming since the age of 12, and after getting his medical degree he went into software engineering full-time.
Right now, Artem is working on the future of collaborative web development at CodeSandbox!
💡 How Did The Idea Of Mock Service Worker Come Up?
MSW started from a question: What are my pain points with API mocking? Back in the day, we were using a standalone mock server at work, and needless to say the experience there wasn't exactly smooth. You had to request totally different URLs just for the sake of testing, you needed to ensure the mock server is running, and, most importantly, you needed to write and maintain the actual server, regardless if you chose a plain server approach or a third-party library. It led to more problems than it solved. So, eventually, Artem began wondering what an ideal API mocking solution would look like? And that's how MSW was born!
🚘 The Journey So Far
What started from a question, became a purpose. Artem started jotting down the criteria to define an API mocking solution.
It came down to a list of criteria to define it:
- Doesn’t require any changes to the application: no conditional request URLs, no stubbing of request clients.
- Has minimal runtime cost: no need to spawn it in a parallel process, no need to build/compile it.
- Works with any request library, whether it’s a native Fetch API or any third-party tool I may decide to use.
The list felt surreal at best. That was until he learned about the Service Worker API, which is an essential tool for caching in progressive web applications. That API allows to intercept requests on the network level so you could respond to them from the cache. Turned out, responding from cache and responding with mocks weren’t that different. That sounded perfect!
Well, it wasn’t. There were still quite a number of obstacles to using the Service Worker API to implement an API mocking solution. Luckily, nothing a couple of months of iterations wouldn’t be able to overcome.
🗒️ Ending Notes
Artem wants to thank Appwrite and to quote him:
"I would like to use this chance to thank Appwrite for selecting my project for their OSS Fund! This means a lot to me and it gives me hope that I may pursue open source full-time one day. "
If this story resonates with you or your friend, tell them about OSS Fund, as applications are still open:
Appwrite OSS Fund
Appwrite provides web and mobile developers with a set of easy-to-use and integrate REST APIs to manage their core backend needs.
appwrite.io
Top comments (3)
I'm extremely honored to receive your support!
Love the OSS fund! 🥰Great to see this sort of thing.
NOTE: You may want to update the post title to "Appwrite OSS Fund Sponsors the Mock Service Worker Project" -- when I first read the title, it read to me as "the sponsors of appwrite OSS fund mocked someone who is a service worker", which would be concerning.
This is a great suggestion, thank you! Will update it right away.