We are beginning development of an Angular 2 application. Our back-end will be using ASP.NET Core WebAPI.

Although my subject calls out authentication, this also applies to any API service that is-but-kinda-isn't required for the client-side app to function. Specifically, authentication, logging, etc.

Right now we have to spin up several services in order for the Angular app to fire up. This is a huge pain in the butt. Ideally, I would like for us to have a "development" flag that we turn on so that we can merrily go about developing on our local machine without dealing with configuring back-end services that aren't really required in order to perform general coding.

I'm curious how other development houses deal with this. This is our first time working with client-side web development. Our previous application was Silverlight/WCF and everything was contained in a single solution. All one had to do was hit F5 in Visual Studio and off you go. Ideally this is the kind of development experience I'd like to have.

  • Thats a good question. Same here with Angular 2 and Spring Boot: i need to launch a VM and 3 spring applications before the angular code will do anything more than show a white screen and print 401 errors in the console
    – marstato
    May 12, 2017 at 22:14
  • 1
    "hit F5 in Visual Studio and off you go" is pretty much exactly what you get if you create the Visual Studio project using the dotnet new angular command line described here: jonhilton.net/2017/02/21/… (I've personally just tested this against using VS2017, dotnet core 1.1, node.js 7.10 and IISExpress on Win10 - The hit-F5-to-go seems to work fine after you build it for the first time. The first time you build it takes a while for npm install to run and get all the node_modules) May 13, 2017 at 9:54
  • Well, that was sort of a contrived example. Same problem will exist in Visual Studio if the client app is dependent on some external API service. May 13, 2017 at 13:47

6 Answers 6


Can all the angular code be served as static files? If the front end can be served like that, you can spin up a simple web server to serve static files.

For the backend, it depends on what sort of API responses you need to work on angular. If you can mock responses by serving static JSON files, then by all means just do that. For each API response you need, create a JSON file with some sample data and serve them as a static file with a 200 response. If you need an authentication endpoint to return a token to simulate a "login flow" then just return some nonsense token.

  • The main pain point right now is the authentication back-end. We're using JSON web tokens for authentication so I'm not aware of an easy way to "fake" those (and I should hope there isn't!) during development. Ideally, the app wouldn't perform any sort of authentication at all if in development mode. May 13, 2017 at 13:51
  • @JakeShakesworth that doesn't seem right to me. Can you explain the actual issue in detail? Why not just have test users and log in with them during development? Is this because you're developing the front end against a production API server!? You need to say more, I don't understand what you're trying to accomplish. May 13, 2017 at 14:59
  • @JakeShakesworth when you say "ideally the app wouldn't perform any authentication at all" I get scared. There should not be any code path in your API ever that allows use with no authentication. That sounds really dangerous to me and very unnecessary. May 13, 2017 at 15:01
  • I agree, I'm not suggesting there should be a path within an application to allow for unfettered access. However, for example, right now if all I want to do is a simple change to an Angular component, I will need to point the application to an authentication server just to see the result of my code change. Or, if I want to run the auth api on my local machine, I'll need a database installed, IIS configured, etc. etc. For my point of view this is annoying and I'm trying to understand if all client-side devs typically deal with this hassle. Or maybe we're "doing it wrong." May 14, 2017 at 23:04
  • I need more context to give a more detailed answer. Here's a question: once a user logs in and is authenticated, what is that screen? What happens if you navigate to that screen on a local dev server with no backend server running? May 15, 2017 at 14:32

Ideally, I would like for us to have a "development" flag that we turn on so that we can merrily go about developing on our local machine without dealing with configuring back-end services that aren't really required in order to perform general coding.

Ok. Go ahead!

In my projects, I've done various things, depending on the need. We've stood up development copies of our API's -- always available. We've created client side service mocks, full client API's that persist in local storage. And we've created really thin fixtures, static responses for each method.

Depends entirely on your needs. Do what you need to do to be efficient without losing fidelity with your actual services. The only wrong answers are the ones that don't work or lead to breakages in your development environment.


One possible approach: have a server which serves all the functionality that does not need authentication, i.e. has no per-user content. Ensure your firewall does not allow external access to it. Add rules to your public server that makes it a reverse proxy to the internal server; ensure that this is available only to authenticated users.

Another possible approach: make template pages that are public. Put all the content that requires authentication in web services, called by AJAX requests that use an AUTH token.

Either approach partitions your app into a public part, and a secure part.


One way I’ve seen this done is to use something like Swagger to document the API first. Swagger has a number of mock clients that are easy to use, and will basically gin up dummy serrvices based on your API design. The fromt end guys work against that and the back end guys write server code that fulfills (and is tested against) the same contract and then at some point you integrate the two. But the integration is simply changing the URL from the local mock server to the the real server.

Also, it sounds like you’re not using any kind of clientside build tool (eg webpack). There are a lot of good reasons to use one, but one such reason is to be able to do builds that vary based on environment.


I've worked on projects that mixes web services between shared services (like authentication) and the specific services I needed to work on. The services your applications need to interact with all need to be configurable.

Say you are working on the shopping cart check out screen, and you also need to work on the payment web service.

So you configure your local Angular app to make a call to a shared dev authentication service (e.g. auth.dev-api.company.com). Then configure it to hit your local payment web service (e.g. localhost/api/payments).

Then your local AngularJS app sends authentication requests to auth.dev-api.company.com, but the calls to the payment web service hit localhost/api/payments.

Basically, the URLs for each web service need to be configurable some how so you can use "shared" web services for things you don't care about, and use local web services running on localhost for the pieces you actually need to modify or debug.


I've handled this in a few different ways depending on what was "required" and what was "nice to have" in order to develop. As you've identified, sometimes you just don't care to spin up all the different parts and pieces to stand up the app so you can check a CSS fix. How you handle it depends on your environment.

Configuration to Use Existing Services

If you have a stable dev/test environment with the required services, it can be easy to just change your config file to use those services. Why turn on your own version of the API that hasn't changed in months when you can use the identical version on the dev server? This is predicated on the stability of such things and having access to use those services. Some services won't be available in such a way, so this may not work.

Another option would be to install IIS / Apache / etc locally and set up the appropriate services to just be ready all the time. So you never have to worry about starting them up every time you want to develop. They are just there waiting for you whenever you need them.


If you can't use existing services, if you have good dependency injection you can leverage that. Once we had to do some testing of a shopping cart web page. And we wanted to run automated tests that would have had to hit the payment gateway API just to get a response so the code could move on. But our CI server was silo-ed in such a way that we couldn't access those APIs. So we used some configuration and DI tricks to use some testing/mock payment API classes. (Since testing the 3rd party API wasn't the important part of the test, this was fine.) We just stubbed out a class that would return some "good enough" response for our code. If possible, you might be able to just stub out a mock authentication access service that just always returns a good response for development only.

Make Standing Everything Up Easier

On other projects, mocking things with DI wasn't a viable option and there weren't really good options for using test/dev server services. In those instances we spent some time making setting everything up easier. On one project we set up a Docker container that we could start up that would start up all the little services we needed. One quick shell command, wait a bit for it to all start up and BAM, everything we needed. On another project, we just wrote a shell script to just start up the appropriate projects/websites/exes. This is the brute-force type of solution for where there just isn't a better alternative. It works when you can't leverage other techniques.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.