Project Apollo - the blueprint for the first version about service-mocker

[vincentbel]

Before diving into the implementation detail, I'd like to point out the main use cases of this library we can see now, which I think will help to polish our public API.

As far as I can see, there exists two main purposes of mock server:

1. Daily development

Mostly, frontend programmers would use a test backend in daily development. But sometimes when backend is not ready, frontend programmers would likely write some mock API response.

Besides, the mock API responses even can be reused to do testing(the following second purpose).

2. Testing

This is big one. With service-mocker, we can nearly test our app with least mock. But there exist some limitations:

• tests must be run on browser(like karma, but not jest)
• browser supports are poor now
• we can't test compatibility of our app now

---

There must exists more use cases I haven't covered above. As for the main two use cases, I think service-mocker need:

1. client side code is simple (even no client side code)
2. easy to write mock server code.
   • I think it is meaningless for developers to set up a full-featured mock server. Developers should write mock server code easily like nock, but rather than a full-featured express app.
   • As a lib, maybe we can provide the power to write a full-featured server app. But I think the easy way should implemented first.

@idiotWu these are some of my thoughts about service-mocker, what's your opinions?

[idiotWu]

@vincentbel yeah I agree.

Actually, I have been thinking about the second point - testing - these days and all the conclusions lead to one thing: patch up XMLHttpRequest. As long as we patched xhr, we can:

1. Full compatibility.
2. Be able to run tests with something like jsdom (or any environment that includes XMLHttpRequest constructor).

And as for the daily devs, I think it would be much simpler to run a script in browsers than set up a server - for which you'll have to write some manuals for newcomers in your team 😢

In my thoughts, this lib should be a minimalist one. There's no need to create an express in browsers, the client-side API includes a register method and a storage service only, and a get/post/any router plus storage service for server-side API.

What confusing me now is the request/response interfaces. I have no idea how far we should go.

---

PS: we can even remove storage service from client's API if you want ;)

[idiotWu]

v1.0.0 is out 👏