What would be the most elegant way to mix RESTful API and some HTML rendering views?

[oleksandr]

Posting it here as I don't see much activity in the chat or stackoverflow around goweb.
The pain of integration with certain payment providers requires a couple of HTML pages to be rendered by the backend, where the user can perform some minimal interaction.

What would be the good practice here when the whole backend is build with goweb?
Options:

1. Implement with goweb and expose via /html or similar (while the API is exposed via /api)
2. Implement with pure go net/http package as part of the SAME server and expose via something like /html (while the API is exposed via /api)
3. Implement with whatever you feel comfortable but run as a separate server.
4. Other options?

[matryer]

If they’re static pages - you can use the MapStatic stuff alongside the other controllers. Usually there’s no folder prefix for html pages, they’d just be “payment/x.html” or whatever.

BUT where will you be hosting this in production!? nginx might be a nicer way to route the static stuff through?

Mat

On Nov 10, 2013, at 12:28 PM, Oleksandr Lobunets notifications@github.com wrote:

Posting it here as I don't see much activity in the chat or stackoverflow around goweb.
The pain of integration with certain payment providers requires a couple of HTML pages to be rendered by the backend, where the user can perform some minimal interaction.

What would be the good practice here when the whole backend is build with goweb?
Options:

Implement with goweb and expose via /html or similar (while the API is exposed via /api)
Implement with pure go net/http package as part of the SAME server and expose via something like /html (while the API is exposed via /api)
Implement with whatever you feel comfortable but run as a separate server.
Other options?
—
Reply to this email directly or view it on GitHub.

[oleksandr]

Thanks. I'm aware about MapStatic, although we don't use it - rather serving the client app directly form the front-end nginx. In the case I described above the pages are "dynamic", rendered on the server-side. That is what makes this a bit more complex. I guess moving towards client-side rendering and just adding additional API here would be the cleanest way to k.i.s.s.

[matryer]

Yes - that's what we prefer. But if you have to do rendering on the server, just use goweb.Map to map to a different set of functions that do the work. Go has quite a few templating frameworks too (I like mustache).

[oleksandr]

That was the final way we went. So we just mapped a handler with goweb.Map and used

ctx.HttpResponseWriter().Header().Set("Content-Type", "text/html")
return goweb.Respond.With(ctx, http.StatusOK, body.Bytes())

to render the HTML.

BTW, if that can be anyone helpful - we didn't want to lose the beauty of 1-file deployment bringing in just a couple of template files. We used this great tool to compile template into the final binary: https://github.com/jteeuwen/go-bindata

The dev pipeline became not that complex: edit html, run go-bindata something like:

bin/go-bindata -prefix="template" -pkg="templates" -uncompressed=false -out=./src/mypackage/payment/templates/index.go -func="IndexTemplate" src/mypackage/payment/templates/index.html

and then simple import index.go and use IndexTemplate variable to Parse/Execute (in case html/template is used).