Last week, for my software-engineering boot camp, I had to work on a team of four. Each teammate was required to develop their own service for a product page, and develop a reverse-proxy that would serve each service.
Before going further, I'll briefly define “Service Oriented Architecture” and “Reverse-Proxies”. Each service in a S.O.A. embodies the code, dependencies, and data integrations necessary for the service to run independently of every other service in the architecture. Of course, some of these services may need to communicate with each other for data, but this data shouldn't be the determining factor as to whether or not the service successfully functions. “Reverse-Proxies” are servers that act as middle-men between the client and the web servers providing each service. R.P.s can have many features that go beyond the scope of this post- like balancing the load between internal servers, caching content to further reduce the load on internal servers, or adding compression/ TLS encryption to the communication channel between the client and R.P.– but all you need to know for this post is the practice of R.P.s hiding the existence and characteristics of the origin servers for each service being rendered.
Now that we've briefly defined S.O.A. and R.P.s, I'll discuss how I was able to develop my own service, and then how I was able to not only render my service, but each of teammates' services' through a R.P.. The functionality of my service, or the purpose it served, isn't relevant to this post. What matters is understanding that my service was built using React.js, and that it could stand entirely alone and be rendered through its own local server without failure. There is no coupling at all of state, logic, and uptime between mine or any of my teammates' services'. In the case that my service makes a request to another service for data, and the services' are not yet brought together by a R.P., then the request simply fails with an error code, of 404, and my service is still able to display the rest of the data it owns- rather than collapsing.
On top of this, the AJAX requests that get sent from the client, in search of needed data for it's component, get intercepted by the R.P. and then forwarded to the respective server which owns the needed data. Since “CORS” in enabled, these internal requests being sent from the R.P. should be a breeze. Once the data gets sent back to the R.P. from the respective server, the R.P. then sends this data back to the client to fill the respective components.
If you enjoyed this post and found it to be helpful in anyway, then please like, share this post, and follow me. That would be highly appreciated it!