You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 17, 2021. It is now read-only.
Hey guys, welcome to the future! This is the outline of service mocker.
0x00 - Explaination
API mock service sucks
Generally, there are two ways to mock an API for your front-end projects:
Set up a temporary server to provide the mock data.
Write mock data directly in your codes.
For the first one, you may have to do tons of works just to set up a simple server. And for the second one, you have to pollute your codes with fake data. What if there's a magic that allows you to mock in front-end and act just like a real server?
Today, with the service worker API, we can find out a way to intercept requests and respond with real HTTP responses that are generated in the service worker context. That's the main idea of this project.
Advantages
Easy to set up.
Real requests that can be inspected in dev tools.
No proxies, no separate server addresses, no CORS issues, no pains.
In an ideal world, only scripts for service workers are needed for running a requests interceptor. But as there are so many limitations with service worker, we are likely to wrap a client runtime for it.
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:
client side code is simple (even no client side code)
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?
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:
Full compatibility.
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 ;)
Hey guys, welcome to the future! This is the outline of service mocker.
0x00 - Explaination
API mock service sucks
Generally, there are two ways to mock an API for your front-end projects:
For the first one, you may have to do tons of works just to set up a simple server. And for the second one, you have to pollute your codes with fake data. What if there's a magic that allows you to mock in front-end and act just like a real server?
Today, with the service worker API, we can find out a way to intercept requests and respond with real HTTP responses that are generated in the service worker context. That's the main idea of this project.
Advantages
Disadvantages
0x01 - Infrastructure
In an ideal world, only scripts for service workers are needed for running a requests interceptor. But as there are so many limitations with service worker, we are likely to wrap a client runtime for it.
0x02 - Features List
Client
Server
CC @vincentbel
The text was updated successfully, but these errors were encountered: