Microservice testing and debugging
Postman collections
When developing apis and endpoints locally it can be a little annoying to refresh and run the process just to test the API again.
Postman collections can be found the following repo
Most services we work on in DWP will be under Collections/Linux_Services.postman_collection.json
Verifying URLs
When testing microservices you sometimes need to verify that the webapp is using the correct microservice.
Here we're looking for a feature branch and what is currently being used by the webapp in the same feature branch sphere. Verifying which microservices is being used for kick tolerance calculations
Example
Info needed:
- Feature branch:
abp300-kicktol-dialog-move-deliver
-> 14 first chars name:abp300-kicktol
- Namespace:
dwp-system-akerbp300-dev
(this is usually where we find feature branches) - Microservice original name:
microservice-kick-tolerance
(find this using kubectl)
Calculated info:
- Service url (for proxy.conf):
https://${CLUSTER_URL}/services/abp300-kicktol-microservice-kick-tolerance
To see which service is actually being used by the deployed webapp we can run
kubectl -n dwp-system-akerbp300-dev get virtualservice abp300-kicktol-webapp-dwp-webapp -o yaml | grep kick
Here we can see two entries for host
in this case the webapp is using the feature branch version of the microservice.
Debugging local microservice via the web app
Use case You're debugging a microservice on your local dev machine and want to test it in dwp-app
- Make sure your microservice is running locally, see below how to setup in Java. They normally use localhost:8080
- Stop
dwp-app
if it's already running. - Go to
proxy.conf.js
. - Search for the service you are developing in e.g
microservice-kick-tolerance
. You should find this entry:
Change the target
to your local microservice url e.g:
Check which port your microservice is running on for nodemsp and javamsp you can use environment variable MICRO_SERVICE_PORT=<PortNumberOfChoice>
- Start
dwp-app
again and now it should be proxied to your local machine instead. You can verify this by looking at the terminal of the locally running microservice. You should see all incoming requests.