Building a Go Web App in 2017

Building a Go Web App in 2017(grisha.org)

23 points by infosample 9 years ago | 8 comments

grey-area 9 years ago |

Apps whose user interface is fully JS-driven are sometimes called Single Page Applications, and are in my opinion the future.

Can't wait for this trend to be over. In many cases it results in slower performance and it certainly makes rendering performance really uneven as the device is asked to do a lot more work. Plus you have to write half your code in is, the Go is just a glorified wrapper around the db here spitting out JSON.

This is not the future I want.

zackify 9 years ago | |

It definitely is the future. You wouldn't load all the JS at once, you split it up on each page. Combine this with devices getting faster and faster plus server side rendering and there's only the upside of instant page changes when using a service worker to load next pages ahead of time on the client. So you would rather not have faster sites then?

noir_lord 9 years ago | | |

You can have a hybrid approach and it's one I've used for 4-5 years.

I bundle library.js (very slowly changing core libraries), bundle.js (common subset amongst the set of files passed) and then page/function-specific.js.

library.js very rarely changes, bundle.js changes less than I thought it would initially and page specific stuff is changed cheaply since the files are typically <2kb.

Since the code that gets worked on the most is page/function specific the entry points any bugs that do creep through are isolated to that page/function and everything else works fine (handy with JS where a bug in your entire site-bundle.js can break the whole application).

I've even split off heavy libraries into bundles that work with library.js so things like ckeditor and datatables can be included and just work without been bundled into the main library (lots of users will never use ckeditor, lots will never use datatables, pretty much only admin/managers will use both).

That way you get the benefits of an SPA (lots of interactivity, json stuff, passing data back and forth conventiently, reusable components, base 'classes' for viewmodels etc) without completely handing off everything to the client and it means you can do routing and such on the client still.

Since all the data that is passed back and forth is just JSON you can also bind the data on the initial page load and pass it down with the page on first load and then immediately bind it with subsequent updates coming in.

It's made it incredibly easy to refactor large applications as well since the backend is 'just' and API, communication is done over simple JSON structures and the end points can be re factored incrementally from one thing to another.

I'm not sure if the pattern has a specific name (I'm sure it does) and I'm certain I didn't originate it, it just seemed like a good fit for the problem domain I'm working in.

Back when I started doing this TypeScript wasn't really a thing and I both didn't trust myself (I wasn't a strong JS programmer) or JS (I didn't trust it for large projects).

grey-area 9 years ago | | |

The evidence of actual sites in production disproves your assertion. Look at this site or the d language forum for speed. No need for to make a js frontend, and in many cases no need to load pages incrementally.

You can use plain Ajax and where appropriate while rendering server side. You can do incremental updates in the isolated cases where it is required very easily without moving everything to js on the client.

softinio 9 years ago |

I totally agree with this blog post do not use any so called web framework stick to the go std library as much as possible.

noinsight 9 years ago | |

But IIRC, the standard library doesn't offer any support for sessions, i.e. signed cookies. That's kind of mind boggling to me. How common are web services without any kinds of sessions?

These sorts of omissions make me question what the language authors are even doing with the language if they haven't come across that need. Or maybe they just didn't share their solutions.

I have more:

Password generation. I come across that need very often in the type of stuff I do. It's pretty trivial to implement (at least something that works without considering performance), but why is this sort of stuff not included in the standard library (Python doesn't have anything either IIRC)?

Unique identifiers. Go doesn't have a library for UUID's in the standard library. I want to generate UID's for logging so I can group separate log lines into a single request (so something "fast" and doesn't have to be 100% guaranteed unique). Would have to use something 3rd party.

elsonwu 9 years ago |

Putting everything into one big Model struct is a good practice?

omginternets 9 years ago |

Sooooo basically the same as in 2016 and before?