

Rapid AngularJS Prototyping Without Real Backend - patelsan
http://www.codeorbits.com/blog/2013/12/20/rapid-angularjs-prototyping-without-real-backend/

======
davidbanham
I did this on a client project recently, but ended up moving away from it. I
Found it falls down when you have different devs working on the same features
from different ends. Instead, I used JSON files that the back end would just
serve from the routes I expected.

Firstly, it provides a clearer and more obvious contract with the back end,
one that you can see in the network traffic.

Also, when the endpoint is actually implemented on the API, it all Just Works.
There's no intermediate step of pulling out the mocks and letting the real
data flow through. It also provides a simple smoke test path during
development of the endpoint.

------
AYBABTME
I've done a project with Angular where I coded a quick fileserver serving a
structure of JSON files that was mimicking a REST API. So you'd have:

    
    
        /collections01/member01.json
        /collections01/member02.json
        /collections02/member01.json
        ...
        /collectionsNN/memberMM.json
    

And I would respond to GET and simulate POST/PUT/DELETE in memory. While I was
working on the backend proper, my teammate could just assume that the backend
was 'working'. Then when I was ready, I wired in the real implementation.

The advantages I found of doing this server side instead of client side (like
in the article) was that the network round-trips were real, thus we'd know
when there was something too inefficient going on. Plus, we would work on the
same domain objects (captured in the JSON) so there was no hurdle when I wired
the real implementation. Finally, I used the JSON files to stub some fake data
into the database when we wanted to test it out.

~~~
Bahamut
Ideally, I think something like this is good, but for prototyping, I think
$httpBackend is a good solution. I'm on a mid-sized project currently where I
implemented a mock backend with $httpBackend, and use a fetch node script to
pull all of the json we want from our daily build for development locally.
When we need to compile our assets and prepare it for deploys for testing on
the daily server, we have a nice grunt script to do that and test things out
on the daily build.

When a frontend dev is rapidly building out features though, he/she shouldn't
be concerned with the performance of the backend - having a full stack dev
server to accompany a mock backend for local development or some sort of local
solution is ideal.

------
shaydoc
I've been doing this for well over a year now on my html5/js apps.

I have a custom data access layer that returns a promise. The data access
layer mocks RESTful services. I have a databootstrap.js that gets put in local
storage on app start, and hey presto a fully functional prototype....

Its definitely a great way to work, it really engages your client/end user and
the feedback loop becomes smaller. Once your done, your client side is mostly
finished.

------
Bahamut
I've done this for a couple of apps now - it is an excellent way to prototype
when you know what the data from the api endpoints will look like, but you
don't have a real backend to test against. It lets you rapidly build a
frontend without worrying about the backend.

However, it isn't the best solution for everything. It's possible to have your
workflow bogged down by refactoring logic if the api for the endpoints are in
flux.

------
mildtrepidation
Maybe I'm looking at this the wrong way, but the emphasis on certain languages
and frameworks for "rapid prototyping" strikes me as short-sighted.

Sure, if you learn them well, you can build a proof of concept quickly. But
unless you currently do everything in C... shouldn't you already be able to do
this with whatever technology/ies you're already the most proficient with?

~~~
nostrademons
Depends what "whatever technology you're already most proficient with" is.

I think that any of Angular, Backbone, React, JQuery, Django, Rails, Node.js,
PHP, and many others are fine for prototyping. Use whatever you're most
familiar with.

However, if all you use is Java, or C++, or Google Closure - you're probably
gonna have a bad time. Some technologies are built for mature projects with
dozens to hundreds of developers. They pay a large tax to manage the
complexities of large projects. If you're just starting out, you'll be paying
that tax even though your codebase doesn't require it.

------
tzaman
We use two tools with $httpBackend: rosie
([https://github.com/bkeepers/rosie](https://github.com/bkeepers/rosie)) and
chancejs ([http://chancejs.com/](http://chancejs.com/)) - this makes it super
easy to create complex and random objects for api responses.

------
thruflo
I'm minded to prototype in angular but I'd rather use a generic data backend
like firebase (or roll my own any-path-works rest api using dataset) than mock
http calls.

------
gibbitz
I just use charles proxy's map local and static JSON locally to do this. It's
framework agnostic and has worked since before angular was "a thing".

------
MWil
cntrl+f "not this approach"

~~~
rexreed
I mentally read this as "note this approach"

