Skip to content
This repository has been archived by the owner on Jan 17, 2021. It is now read-only.

Project Apollo - the blueprint for the first version #1

Closed
5 tasks done
idiotWu opened this issue Dec 14, 2016 · 3 comments
Closed
5 tasks done

Project Apollo - the blueprint for the first version #1

idiotWu opened this issue Dec 14, 2016 · 3 comments
Labels
Milestone

Comments

@idiotWu
Copy link
Member

idiotWu commented Dec 14, 2016

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:

  1. Set up a temporary server to provide the mock data.
  2. 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

  1. Easy to set up.
  2. Real requests that can be inspected in dev tools.
  3. No proxies, no separate server addresses, no CORS issues, no pains.

Disadvantages

  1. Poor compatibility: http://caniuse.com/#feat=serviceworkers
  2. Weird behaviors among old version of browsers.

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.

  • Client
    • storage
    • service worker updater
  • Server
    • router
    • request and response layers
    • storage service

0x02 - Features List

CC @vincentbel

@idiotWu idiotWu added this to the First Release milestone Dec 14, 2016
@vincentbel
Copy link
Member

vincentbel commented Dec 17, 2016

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
Copy link
Member Author

idiotWu commented Dec 17, 2016

@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 ;)

@service-mocker service-mocker locked and limited conversation to collaborators Jan 8, 2017
@idiotWu
Copy link
Member Author

idiotWu commented Jan 18, 2017

v1.0.0 is out 👏

@idiotWu idiotWu closed this as completed Jan 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants