What's a proper design pattern here?

I have written an http daemon that follows the REST paradigm. My original goal was that once finished I will write a logic in a frontend web application. But that has turned out to be a bad idea, mainly due to my lack of experience with frontend development. So now I am juggling the idea to build yet another http daemon that would act as a proxy between a browser and the REST API. The proxy would be responsible for generating HTML content based on data obtained from the API daemon, taking advantage of the templating package found in Go.

This is my proposed setup:

(client) <---> nginx_reverse_proxy <---> webd <---> apid

Is this a common pattern? If so, there’s definitely a package that might do the heavy lifting for me. I am aware of https://golang.org/pkg/net/http/httputil/#ReverseProxy but it seems I am not able to intercept response data sent by apid.

Is there a one-to-one relation between a web page and an API call? Only then would such a proxy be able to simply translate a call to webd to exactly one call to apid.

If this is not the case, if you would have to make multiple calls from webd to apid to build the HTML response for a call to webd, you will have logic to implement. This logic would have to know which parts of the HTML response would require which data and which calls to apid would be necessary to get it. This logic is something no existing package or framework can implement for you. You will have to write it yourself. A MVC framework perhaps can help you route requests and build the HTML response.

In fact, this logic is the same as a web frontend (written in JavaScript using XHR calls) would implement. Only the layer where the logic is implemented would differ: in webd or in the browser.

In todays web I would recommend to learn the web frontend way.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.