Using Nexus OSS Repository in An Isolated Environment

No Internet Access, No Libraries?

In our workplace, like in many other big firms, government offices, and banks, the internal network is isolated from the outside world. Nothing goes out and nothing goes in. But, how can you conveniently work with open source libraries if you cannot use Maven or npm (and other repositories) to fetch needed libraries?

Nexus, and other similar products can be installed in pairs, to bridge between networks. But as far as I know, that topology can only work in synchronous mode and you cannot add your own asynchronous checks like using sandboxes or anti-virus checks — and that can be a problem. Plus, we wanted to use only the free, open-source version of Nexus (OSS), as we try to rely on open source as much as possible.

Extending Spring Boot’s Zuul Proxy to Record Requests and Responses

An easy way to capture the incoming requests to your server and replay them can be very useful. For example, if you lack an automation team, or simply want to be quick about it, you can record the REST requests of a scenario and play them again after every push to GIT. You can also use the recorded requests to simulate many users. Or, you can analyze the requests to learn useful statistics, etc. You get the idea.

OK, so how can we do it the easy way? First, we’ll exploit spring boot Zuul gateway filters feature – this gateway can activate custom filters for every request and every response. A handler must simply extend ZuulFilter and provide information of:

Developing Spring Cloud Microservices With a Central Environment

How can developers work simultaneously on the same central Spring Cloud environment?

Developing software based on a microservices architecture is extremely easy when you use Spring Boot and Spring Cloud. Just throw in a few lines of code and you can have a microservice up and running. But how do you develop a real-world application in such an environment? In theory, each microservice is isolated and can be developed alone, but, in practice, this is often not the case. To develop and test your service in the context of the application that uses it requires more than just your microservice to be up and running. So, how can one conveniently develop in a multi-microservices environment?