Backend-less UI Development

Backend-less UI Development

While the modern web development environment has many tools for easily setting up and running your backend (via package managers, dependency managers, migrations, etc.), there are still some advantages to having a simple mock backend that allows a single-page application to be run literally after a simple checkout. I will show a simple exploit to use any static web server as your mock backend. An HTTP transport adaptor for your favourite library (jQuery being one) can also be used for the best effect; simulating HTTP verbs, HTTP response codes, as well as latency.

C7f65a2f291636c0bd19920b2b6d525b?s=128

Ates Goral

March 16, 2014
Tweet

Transcript

  1. 2.

    tl;dr • A simple approach for mocking an application server’s

    API. • An implementation + demo of it. • A discussion around pros/cons of mocking your API like this.
  2. 3.

    Mocking Your API “You’re not RESTful and you reek of

    RPC!” Simulating a backend with scripted responses in order to aid development and testing.
  3. 4.

    about:me Hi! My name is Ates Goral, which is pronounced:

    “Atesh Gir-uhl”, because it’s actually spelled: Ateş Göral
  4. 6.

    about:me Done: 8bit, 16bit, 32bit, 64bit 68000 Assembly, Object Pascal,

    C++, Java, other things... Then HTML/CSS/JavaScript = bliss :)
  5. 7.

    The Premise Single Page Application (SPA) with a usually stateless

    backend API Application state is on the UI
  6. 10.
  7. 11.

    MyPets > git clone https://github.com/atesgoral/demock > cd demock/examples demock/examples> bower

    install demock/examples> npm install -g serve demock/examples> serve .. http://localhost:3000/examples/angular.html http://localhost:3000/examples/jquery.html
  8. 12.

    A SPA Can Be Very Complicated • 100’s or 1000’s

    of JavaScript modules • Plug-ins • Many external services • Many ways your environment can break
  9. 14.

    Rendering Typically, a view can be rendered with just GET

    requests: • GET /lib/jquery.min.js • GET /scripts/main.js • GET /api/user/status • GET /api/bills ...
  10. 15.

    A Trivial Realization Default document feature: GET requests against an

    API can be simulated with a static web server. GET /api/entities → GET /api/entities/index.html
  11. 17.

    MyPets - List + Details Add an index.html file under

    /api/pets: GET /api/pets → 200 OK Fast forward: demock/examples> git checkout get-api
  12. 18.

    What did we just accomplish? • Render an entire application

    without its backend, however complex it may be • Not a single line of change to our application • No external tools, frameworks added -- just a good old static web server
  13. 19.

    Problem: Content-Type index.html → text/html :( index.json → application/json :)

    Angular doesn’t care. jQuery does. I haven’t checked other libs.
  14. 20.

    Solution 1 Configure static web server: • Default documents +

    index.json • MIME types + .json → application/json
  15. 23.

    Problem: Other HTTP Methods Can’t simulate POST, PUT, DELETE, etc.

    with a static web server. Need to start tapping into the HTTP transport layer.
  16. 25.

    Convention: Append Method to Path POST /api/entities → GET /api/entities/POST

    → GET /api/entities/POST/index.html DELETE /api/entities/1 → GET /api/entities/1/DELETE → GET /api/entities/1/DELETE/index.html
  17. 26.

    MyPets - Sign In Add transport interceptor and an index.html

    file under /api/signIn/POST: GET /api/signIn/POST → 200 OK Fast forward: demock/examples> git checkout post-api
  18. 28.

    Request & Response Filtering Intercept, modify, pass down; then up.

    APPLICATION INTERCEPTOR REQUEST & RESPONSE FILTERING TRANSPORT
  19. 29.

    MyPets - Sign In - Response Filtering Special properties in

    the response object to trigger changes to the response. Fast forward: demock/examples> git checkout master
  20. 32.

    demock Library-agnostic and convention-agnostic APPLICATION TRANSPORT ADAPTOR TRANSPORT demock Request

    Request & Response REQUEST & RESPONSE FILTERS Request Request & Response
  21. 35.

    demock - Stock Filters • $method - append method to

    path • $defaultDocument - append default document to path (disabled) • $delay - introduce latency • $timeout - trigger HTTP timeout • $status - override HTTP response status • $switch - conditional responses based
  22. 36.

    demock - Filter Ideas • $header - set HTTP response

    headers • $repeat - generate massive set of data • $param - parameterize response content
  23. 37.

    What About Production Time? Q: How do you enable the

    mock only at development time? A: It’s application-specific. I don’t have a single answer.
  24. 38.

    Enabling the Mock at Dev. Time Principle: Avoid contaminating production

    code with dev/test artifacts. Do it transparently if you can.
  25. 39.

    Enabling the Mock at Dev. Time • Already have plug-ins?

    A SDK plugin. • Conditional dependencies, versioning • Build pragmas, switches, etc.
  26. 40.

    Prior Art There are blog posts, libraries, and even facilities

    built into frameworks for server mocking. Some are similar to this approach of using statically serving JSON files.
  27. 43.

    Con: Not Exercising the Full Stack Bugs elsewhere in the

    stack may escape. Certain bugs only surface in certain conditions (latency, exact order of asynchronous operations, etc.)
  28. 45.

    Pro: Fast! Once initial setup is done, it’s checkout-and- go.

    Change a single line of code, hit Refresh (or use live reloading) and see the result right away.
  29. 47.

    Pro: Rapid Prototyping Focus on what you need to achieve

    on the UI. Once the API is nailed down, the UI side of things are done. It’s not wasted effort.
  30. 48.

    Pro: Handcrafted Permutations • Bare minimum, fully representative set •

    Establish convention for deterministic naming of entities • Don’t use a backend snapshot full of junk
  31. 49.

    Pro: Edge Cases Easily mock hard-to-reproduce edge cases: • Network

    latency • Request timeout • 503 Internal Server Error • Legacy/incompatible data from backend • Looooooooooooooong text • Ünḯcṏde
  32. 50.

    Pro: Permutations, Edge Cases ✔ DO: • User One, ...

    • John Doe, ... • Jane Withlonglastname • Elmo • 宮崎 駿 ✘ DON’T: • Test User1 • Test User11 • DELETEME • Bob’s Third Test • __TEMPPPPPPP • testing 123^@#
  33. 51.

    Pro: UI-first Design The UI is your storefront • Focus

    on user experience • Interaction design that’s uninhibited by technical concerns • Optimize for performance later
  34. 52.

    Pro: API-first Design • Decouple API from ugly implementation details

    of the backend • Backend is a black box • UI is the primary consumer of the API • API is immediately reusable
  35. 53.

    Pro: API-first Design Specification by Example (SBE) • Save time

    from separately documenting the API via JSON Hyper-Schema, WADL, WSDL, Swagger, etc. • “Here, I want to receive this.” • Leaves no room for ambiguity, reduces feedback loops
  36. 54.

    Pro: Synchronization (bis) Your mock data set and actual backend

    may go out of synch. • Makes you more cognizant about backwards compatibility of your API • Good opportunity to assess the impact to consumers of your API
  37. 57.

    Boulder Dash Cloning Writing Boulder Dash clones == “Hello World!”

    • 68000 (Atari ST, Amiga) • Object Pascal (PC) • No C++ :( :( :( • JavaScript (lost count)