I tried to describe my humble workflow here with a few code snippets: https://zserge.com/posts/go-web-services/
Generally I use standard library, with the exception being github.com/gorilla/mux Gorilla Mux for routing because it removes so much boilerplate.
I do however use Python for all HTTP integration tests. With requests + voluptuous its so much more productive than doing them in Go, which I had previously done.
I write monoliths and render mostly HTML back to the client. I have a few json endpoints around for m2m APIs or to power search boxes here and there.
The main thing I’m hacking on at the moment is https://clubman.app other things are listed at https://notbad.software
A relatively up to date skeleton of my apps is at https://github.com/davidbanham/doubleboiler
My personal website was built using Go and Postgres. I did a lot of it from scratch using the standard library and very few dependencies.
I have my own deployment process using a makefile, git tags, and rsync. Migrations are just a set of sql files checked into the project.
This works pretty well for me since I'm the only developer on the project.
Here's my "tech" page with some information on the website: https://dwayne.xyz/tech
And the portfolio page for the website (on the website): https://dwayne.xyz/project/dwayne.xyz
I have very little temptation to use it for a whole application though. Unless you are already a Go shop I would advise anyone to just get better at making Ruby, Python, PHP, or JavaScript back ends that are more performant.
We use Fiber (https://gofiber.io) as web framework and Pongo2 (https://github.com/flosch/pongo2) as template engine. The Go/Fiber parts are ok, the pain is template engine.
- Pongo2 syntax is like Django/Jinja2, but not as easy as Jinja2. I use Python+Jinja2 for years in production, it's so easy to use and troubleshoot.
- No builtin i18n support. You can find some blog posts or articles introduce pongo2, but no one mentions i18n support/implementation like no one need it. We implemented our own i18n support, but still need a tool to extract strings from template files for translation.
- The macro syntax doesn't support specifying argument names while calling. e.g. `{{ my_macro("a", "b", "c") }}` is ok, but not `{{ my_macro(name1="a", name2="b", name3="c") }}`. It's hard to organize reusable HTML/CSS code snippets.
- Sometimes the custom macro is correct (syntax part), but it renders nothing in output html, but if i add the same pongo2 code in its own unittests files, it works. Didn't find a way to troubleshoot, no clue at all what the problem is.
Anyway, Go itself and the web framework are very good for web development now, just miss a Jinja2 for Go.
The end result are two web applications that work as a backend and frontend for an ActivityPub link aggregator (similar to HN and old redddit).
I mostly develop in Goland as I use the debugger extensively, and I didn't want to spend the time to learn to use delve in the command line.
I tried to keep as much as possible a handmade approach, so I'm making use of the standard library over more fancy packages or frameworks.
In my specific case the biggest issue I had was with the protocol itself (ActivityPub) which allows for a large degree of flexibility in the structure of the JSON objects it passes around, a lot more than the default encoder in go allows for. I had to implement my own functionality for encoding/decoding JSON objects, and I'm currently working on adding similar functionality for binary encoding.
Links to the projects you can find in my bio.
Tools wise we use VSCode, have a good local Dev story and we migrated from sqlx to sqlc recently to speed things up.
We use gorilla mux and build API first with Vue for frontend. Really clean and simple stack with few moving parts.
Workflow: we use VSCode with devContainers (docker-compose local dev env), our tasks are simply defined in a Makefile. Our high-lvl dev workflow is documented here: https://github.com/allaboutapps/go-starter/wiki/FAQ#how-does...
Difficulties: Nothing special actually. We switched from Node.js to Go in the beginning of 2020 and it's been a pleasure for our new projects (software agency). I thought it was going to be hard to onboard our staff / new hires to Go and our stack, but this really turned out to be a non issue.
Revel is often seen as anti-idiomatic because it's a whole framework but it is nice to get a web app going pretty fast (with Go). These days I have a lot more experience and I probably would choose echo or something similar. Not because I think that Revel is bad but because I have a lot more freedom with those.
For editing I mostly use Vim.
Generally I would say if you create web apps maybe choose something different from Go. It certainly can be easier/more comfortable. For APIs it's still great and one of the best choices IMO.
At work the images are deployed on DC/OS, and for my personal projects I use Docker Compose.
The most difficult part (which isn't really that difficult) would probably be the actual deployment part, and that's not specific to Go.
https://pace.dev/blog/2018/05/09/how-I-write-http-services-a...
Use sqlx to extend the std lib.
Have dropped using an orm.
The api is defined with gRPC.io and offered as a gRPC api as well as a Rest api with JSON using grpc-gateway. Database is PostgreSQL using pgx. Caching via Resis or memcached. Building testing via a Makefile with junit and cobertura reports
I have started falling in love with coding/CS again with Go.
Our philosophy is to keep things close to the metal and not use layers as much as possible. Go enables you to follow with approach with the standard libraries that come with the language.
Problem with layers/frameworks is that while they seem to solve immediate problem quickly, layers will rear their ugly head down the road , making you feel helpless during debugging
We use standard libraries
database/sql for database html/template for UI
Only external package used so far is gin-gonic/gin for middleware&routing
We have only negative experiences with frameworks and big layers. They solve problems quickly in the beginning, but they always end up causing problems. Years later, debugging strange errors, security issues, etc. The more layers you add the less useful and good the application becomes.
we use the standard library and a couple of slim and well written external libraries, such as sqlx and go-sql-driver.
I have written my own HTML form validator and custom error handler - once you get that done, web development in Go becomes MUCH easier.
We don't use ANY JavaScript on the front-end unless it is a minor custom enhancement to the UI (it must be able to run without). Everything is pure HTML and CSS.
However, I personally do find the HTML templating tedious, but I have always found templating stupid and annoying, this is not specific to Go. I prefer to write HTML inline in PHP (when I do PHP) i.e. the old fashion way. I hate templating in any language!
It's easy to make mistakes in Go HTML templates, make sure you test that part of your code well!
Writing big web applications from scratch is great though, and it's really fast in Go, faster than PHP, as long as you do it right! Documentation, documentation, documentation. Anyone who inherits your code, whether you're alone or on a team, needs to know and understand your thinking and rationale.
The main reason why projects fail when they build tailor made software is because of laziness regarding documentation.
The correct way is to regard missing documentation as a bug! Write the documentation WHEN you write the code. If you change the code, change the documentation right away, when you can still remember what you're doing and why - this is the most important part and why so many code bases are horrible to inherit. Missing or poor documentation.
Never use "clever" code, make code that is easy to read and understand. Don't worry too much about design patterns and philosophy, they mostly belong in the books and in theoretical discussions!
Web development in Go is not for everyone, it requires experience and thoroughness. The build fast, deploy and forget strategy - that most people use these days - doesn't belong in Go.
Go will reward you in the end with really good performance and very easy future maintenance. Nothing suddenly breaks because a third of the standard library has suddenly been changed in the next version upgrade, such as with PHP.
EDIT: Typo.
There are some small things about the language that can feel a little cumbersome (lack of generics for example) but largely happy with the language and the trade offs so far seem worth it.