Can gowebuitoolkit be used (safely) as a web application toolkit ?

[Serge Hulne]

Hi, I understand that gowebuitoolkit is intended to be used as a browser-based interface for desktop applications.


However, since in this particular instance this toolkit happens to be built on web technology (HTML, JavaScript, Ajax, Go web server etc ...), I was wondering if it can also be used as a kit to build web applications in pure Go ?


That would be really cool since:

1. It would not require to use HTML, JavaScript code etc ... in addition to Go code (less maintenance etc ,,,)

2. The same application could be run indifferently as a web application or desktop application (not unlike Java applet).

3. It looks, a priori like a simple way to build multi-platform desktop applications written in Go.  


Obviously, if run on a server, an application built with gowebuitoolkit might do the job (run as a web applicaton), but :

- Would it be safe against obvious internet attacks (code injection, etc ...) ?

- Would a gowebuitoolkit-based application be used in a multi-user context ?



Thanks,

Serge.

[András Belicza]

Hi,

Yes, in my opinion it can be used to build web applications too.

Your concerns:

-I don't see any attack points because no code is executed on the server which would originate from the clients. The server only runs Go code, and none of those come from the client, the running code on the server side is "precompiled" before the server starts. Of course before I would use this in enterprise application, I would double check it.

-Multi-user context? Not a problem. Gowut supports sessions (http-session). Without sessions every user would see the same GUI (the same windows, components etc), so that could cause problems, but if a separate session is created for each client, the GUI that is built and its state is different and is separated from each other.

You can even choose to use authenticated sessions (password protected), or you can create sessions on first request without requiring a password.

One thing that might be disadvantage: The complete GUI exists in the memory of the server, so if many users are connected and many GUI (many pages with many components) objects exist, this might require relatively big memory.

But on the other side: since the GUI exists in the memory of the server, the clients can even close their browsers and reopen, and the same web page and state can / will be reconstructed.