Setting up development environment in micro-services architecture

Question

We are moving towards developing a web app in a micro-services architecture. We thought about running the services behind a API gateway that will handle authentication and will proxy the requests to the appropriate services. We have encountered a problem while setting up the development environment. How can we develop a service in a local machine (laptop) and test and run it in a way that is similar to the production (behind the gateway)?

Consider the following requirements:

• Inter process communication (B2B)
• Manage and sync different versions
• Access the service with authentication token (produced by the gateway)

Our API gateway is sitting in between the client (browser, mobile) and receives the requesqs. Every request should have a jwt token attached to it (generated by the gateway) or else redirected to a 3rd party provider for authentication.
So after authenticating the user (by the cookie or authorization header token) we proxy the request to the specified service.

Answer 1

I'm having some trouble understanding exactly what is the issue in your situation, but if I'm reading you right, your issue is how to organize your development process locally, while still having the flexibility to test externally.

To this I say - don't. If you are going to use an API gateway, test your part of the contract - what happens after the gateway. This way you can capture many issues that may remain hidden otherwise due to the API gateway and furthermore any attempt to test the gateway itself are exercises in futility - you are essentially testing an intermediate layer that has already undergone much rigorous testing than your process (hopefully, that is) and which is designed to hide/obfuscate the finer details of your own API.

Note: I'm in no way suggesting you shouldn't test the end result, too, but I believe your main testing effort should go to testing the code you own and maintain, not an external abstraction layer. Testing the external view is (IMO) for integration testing and for status monitoring (though this is more often than not provided by the API gateway provider).

As for how to setup and organize the process, I suggest using Amazon API Gateway or its competition (I've only worked with AWS, sorry). The very purpose of this service is to abstract away API-specific concerns, while letting you focus on the substance (it "lets you bring your value" in marketspeak) of the service.

Touching on the issue of redirecting requests to the 'local' development machine (note this isn't really in scope of this site, so I'm 'trespassing' somewhat, if you will), you can always use some VPN technology to connect the laptop to the API gateway. In terms of AWS, I believe VPC should allow this - take a look at this reference.

Finally, this question cries 'devops', which is why I'd like to take the time to point out that any such considerations are best discussed with the more 'sysadmin-y' colleagues, as their expertise will be essential in setting up something like this.

Answer 2

You have a few options, depending on what kind of testing you're doing. For quick, manual testing with postman, you can go to jwt.io and just copy and paste a token into your headers. You can get a surprising amount of mileage out of this method.

For automated integration testing, you shouldn't actually need a gateway, you can just generate the jwts directly from your test libraries.

For longer-term developer testing, you just need a simpler lightweight gateway that developers can run on their own machines. They don't generally need all the full features of the production gateway, just enough to be able to exercise all the roles. You might be able to find open source projects that do what you need here, or perhaps your service provider has a downloadable version.