Client side web development - dealing with authentication during development

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

DI

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.