Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Difference between Service, Factory and Provider in AngularJS
// Source:!topic/angular/hVrkvaHGOfc
// jsFiddle:
// author: Pawel Kozlowski
var myApp = angular.module('myApp', []);
//service style, probably the simplest one
myApp.service('helloWorldFromService', function() {
this.sayHello = function() {
return "Hello, World!"
//factory style, more involved but more sophisticated
myApp.factory('helloWorldFromFactory', function() {
return {
sayHello: function() {
return "Hello, World!"
//provider style, full blown, configurable version
myApp.provider('helloWorld', function() {
// In the provider function, you cannot inject any
// service or factory. This can only be done at the
// "$get" method. = 'Default';
this.$get = function() {
var name =;
return {
sayHello: function() {
return "Hello, " + name + "!"
this.setName = function(name) { = name;
//hey, we can configure a provider!
function MyCtrl($scope, helloWorld, helloWorldFromFactory, helloWorldFromService) {
$scope.hellos = [

I think it's clearer to write the $get function like this:

this.$get = function() {
    var self = this;
    return {
        sayHello: function() {
            return "Hello, " + + "!"

But it's a minor point. Fantastic example otherwise. Thank you!

I would love to see this example with service / factory / provider that wraps a resource.

@Mithrandir0x Thanks for your very useful Gist!

It was very useful while writing my blog about: "How to create (singleton) AngularJS services in 4 different ways"

Thank you @Mithrandir0x it was very useful for me too.

jonahx commented May 10, 2013

The "provider" example is better implemented with the revealing module pattern. In the form above, "name" is public: there really is no reason to have setName. To make "name" private as intended, rewrite it as:

myApp.provider('helloWorld', function() {

    var name = 'Default';

    return {
        $get: function() {
            return {
                sayHello: function() {
                    return "Hello, " + name + "!"
        setName: function(newName) {
            name = newName;


Also this is a good video on the subject

Its nice to see how they work differently, but why do I need each of them? What do I use them for? Any real life examples on suggested use cases? Maybe a real app with rest and multiple controllers on single page?
Can anyone point me in the right direction? I'm struggling with a simple app wired with a resource and I have no clue how to organize things and make my productListCtrl talk to cartCtrl :/

A believe a service is a singleton and a provider creates a new instance. So if you need to persist some info then a service might be the better way. Someone please correct me if I am wrong. A real world example would be to use a service to retrieve data from a server where you don't want to create a new object every time you need you XHR service object. To be honest i have not used providers at all. So I cannot really speak to their use cases.

I too would like to know a real use case for a provider.


Mithrandir0x commented May 21, 2013

@jonahx True. Relying on variable scope for more privacy concerns is good, although I believe, when Pawel wrote this example, he was showing that when creating a new factory using the function given by the provider, the function was called with the keyword this bound to the provider object itself.

Instead of using a closure, you use this to access to methods and properties of the provider, which Factories and Service have no access to.

gigablox commented Jun 3, 2013


I feel like our solutions are very similar. However, I am using a service which includes various data manipulation methods. Please take a look the implimentation in this example and tell me how you would weigh each of our solutions in strengths/weaknesses --- with the goal in mind of course to share models across controllers.

You will see there is a lot of data manipulation to tweak model so it's ready for the view. I feel like a more complex example is going to serve us better for discussing what the best method is for solving this problem.

Simply great examples. Very useful, thanks a lot.

Thank you very much, this is very enlightening!

I also recommend people to take a look at angular.js source code to understand it better, most specifically, search for the createInjector function, that's the one who hold all the logic of Angular DI, services, factory, services, etc.!

doup commented Sep 3, 2013

You can't inject a service in app.config(), so if you want to pass a service to the provider just inject it in $get:

app.provider('settings', function () {
    this._settings = {};

    this.$get = ['cache', function (cache) {
        var settings = new Settings(cache);


        return settings;

    this.setSettings = function (settings) {
        this._settings = settings;

waskito commented Nov 8, 2013

@doup you say that we can inject service in $get. Can I inject $cookieStore in $get ?

Finally, I understand it

Thank you for the great examples!

What I see is different ways of doing the same thing so far. Can I get an example where one MUST use a service for instance? When using a factory doesnt cut it and you have to use a provider?

Most of the examples above give you a use case for a provider:

look in the first example how you can call setName() on the provider to configure the service. It's under "//hey, we can configure a provider!"

Service is singleton and simple version of Factory. While Factory is a simple version of Provider, Factory is a more flexable compared to service method, and a short handed for configuring a service when $get method is required. Provider creates new object by the $get factory function. Provider is not injectable during run phase or run time while all others are ( Constant, Variable, Service, and Factory), however, Provider is injectable during the configuration phase or compile time.

Provider should be used very sparely as you want to use compile time injection. Usually, Service does most of the job while Factory can deal with more sophisticated logic. Remember, Service is a singleton so if you need to create new object every time, use Factory instead.

dmitriz commented Apr 22, 2014

Here is a very simple example of provider without 'this':

sunew commented May 26, 2014

@gigablox : Thanks for the super example, that really got it working for me. A question/comment: Instead of using events to signal data is ready, wouldn't it be a good just to return a promise. And then let the controller set then on the promise, and set data on the scope from then?

hanmina commented Jun 17, 2014

thanks for useful code block. but I would be happy if you explain each type, purpose and when to use which one.

joshids commented Jun 24, 2014

  1. When you register the Service you return an object, when Angular needs to inject "service" into any component, it will inject this object.
  2. When you register the Factory, you return a constructor function. When angular needs to inject "service" into any component, it will first do a

new factoryReturnedFunction();

and then inject it. This will be done only for the first time service is requested. For all subsequent injections, object created first time will be used.
3. When you register a Provider, it has same behavior as Factory above. The function assigned to ...$get..., will be used as constructor function.

expalmer commented Jul 9, 2014

thanks for sharing, you help me alot to understand.


ghost commented Jul 21, 2014

Nice Info

SAM-BI commented Jul 28, 2014

@Mithrandir0x, thank you for the example!
If we need a service and we define it using the "factory" method, is it write or false?

Thanks, this is very helpful. :)

Thanks much for the explanation. would you tell me, where to use which, I mean, how to make a right choice among them?
Appreciate your time

xis19 commented Nov 18, 2015

Thanks for the helpful example.

webineh commented Mar 3, 2016

very thanks

Many Thanks !

Nice explanation about Service / Provider / Factory, Very useful, Thank you very much !

Nice Explanation. Helpful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment