

Create a food ordering app like JustEat with AngularJS - giuliano84
http://blog.stamplay.com/create-a-food-ordering-app-like-justeat-with-angularjs/

======
cheriot
It's a well done write up and a great tutorial. I wouldn't use it as a source
of best practices, though. The controllers are huge and interact with $http.
And I can't think of a reason for a variable named "globalVariable" with a
random set of attributes. The entire point of Angular's dependency injection
is to avoid that.

~~~
giuliano84
Yes Cheriot, you're probably right but we wanted to keep it easy to
understand. How would you change it? Happy to improve it and make it more
"best-practice" compliant and then share it here
[https://github.com/Stamplay/stamplay-
foodme](https://github.com/Stamplay/stamplay-foodme)

~~~
aikah
I disagree with the OP,in a system with dependency injection,it doesnt matter
where the injected stuff comes from,only the fact that they are injected is
important.

You could have 20 services instead of one it would not make any difference.
Since the details and dependencies of the services are encapsulated. I
would,however separate the modal methods from the config variables, as it's 2
different concerns.But the rest is totally fine.

It's a matter of opinion beyond that, there are no "best-practices",other than
the fact that one should not use any data that is not injected somehow , in a
controller.

Same for $http.Of course one might want to abstract some business logic as the
application grows,because at some point one might need to do complex stuffs
when it comes to api calls(validation,...) but YAGNI over DRY. The code is
still testable.

Again the only thing one should NOT do in a controller is DOM
manipulation,beyond that anything goes.

~~~
Bahamut
I'd say you shouldn't pollute your controller with too much non-UI specific
logic - oftentimes, it's worth splitting off some controller logic that is
heavy into a service to test it in a more managable fashion & confine the
messiness away from the controller.

------
pacofvf
Great!, you should add a payment api (fulfill via stripe, paypal, et-al), most
of freelancer's gigs are e-commerce stuff, you could even take a cut.

------
joshcrowder
Great article, I love seeing finished projects with walk throughs.

We've decided to move to Ember from Backbone instead of going to Angular,
articles like this make me doubt my decision!

~~~
aikah
Both frameworks have their strength and weaknesses. I think Ember is a heavier
and more verbose,but it's easy to integrate third party widgets without having
to rewrite them. While I was coding something to learn AngularJS
[https://github.com/Mparaiso/markme-silex](https://github.com/Mparaiso/markme-
silex) , I spent most of my time fixing race conditions between the digest
cycle and the third party widgets , and sometimes it was reaslly hard to
figure out why the model wasnt updating,or why the view was when the model
didnt change in appearance. ( I had to integrate masonry,bootstrap
modal,tags.input,autocomplete and a few others).

But again,since AngularJS takes care of everything else,that's a
tradeoff.Angular solves the architecture problem with dependency injection.

------
dharma1
how easy is it to migrate a BaaS approach like this (stamplay, firebase, parse
etc) to a self hosted one once things start to scale beyond 10,000 or so
users?

~~~
giuliano84
It depends from the service, everyone has its own lock-in. With us you own the
data and you can take it anytime, the hard part is to code the backend from
scratch on your own.

~~~
dharma1
Thanks good to know. Will give this a try for prototype and then roll our own
backend later.

------
instakill
Whoops, 404 for the demo:
[https://e33b72.stamplay.com/](https://e33b72.stamplay.com/)

~~~
giuliano84
Went temporary offline, try now :)

------
azrak
unsupported on IE8.

~~~
giuliano84
Yes we now, but modern frameworks work with modern browsers. It's a good
opportunity to give Chrome a try ;)

