Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Go web dev notes

jvns.ca

Post reply on HN
Print view View original

111–120 of 154 posts

Re: Some Go web dev notes

#111

Post by glenjamin »

peterldowns wrote: post #86
jrockway wrote: post #54

Earlier quoted context omitted.

I really think the library search is more of something you inherit from other languages, though database drivers are something you need to go looking for. The standard library has an adequate HTTP router (though I prefer grpc-gateway as it autogenerates docs, types, etc.) and logger (slog, but honestly plain log is fine). For your database driver, just use pgx. For migrations, tern is fine. For the tiniest bit of sug…

I've been writing Golang for years now, and I heavily endorse everything written here. Only exception is you should use my migration library [0] instead of tern — you don't need down migrations, and you can stop worrying about migration number conflicts. One other suggestion I'll make is you probably at some point should write a translation layer between your API endpoints and the http.Handler interface, so that your…

This looks excellent!

The go tools for managing DB schema migrations have always felt lacking to me, and it seems like your tool ticks all of the boxes I had.

Except for one: lack of support for CREATE INDEX CONCURRENTLY (usually done by detecting that and skipping the transaction for that migration). How do you handle creating indexes without this?

Re: Some Go web dev notes

#112

Post by glenjamin »

domano wrote: post #100
peterldowns wrote: post #86

Earlier quoted context omitted.

I've been writing Golang for years now, and I heavily endorse everything written here. Only exception is you should use my migration library [0] instead of tern — you don't need down migrations, and you can stop worrying about migration number conflicts. One other suggestion I'll make is you probably at some point should write a translation layer between your API endpoints and the http.Handler interface, so that your…

Bold of you to flat out drop down migrations. I guess having a new up migration to cover the case is better, but its nice to have a documented way of rolling back (which would be the down migration) - without applying it programmatically. But it helps if other team members can see how a change should be rolled back ideally.

The key here is that in production it's almost always not safe to actually apply a down migration - so it's better to make that clear than to pretend there's some way to reverse an irreversible operation.

Re: Some Go web dev notes

#113

Post by JodieBenitez »

thiht wrote: post #98
rwdf wrote: post #93

Earlier quoted context omitted.

I've grown to prefer go-chi over Gin (or Echo), since it's just the standard library with some QoL features on top.

Chi is amazing. I love the philosophy of extending the stdlib instead of writing an alternative. I try to keep that in mind when writing my own libs or helpers now, and I'm very satisfied with the results. For example I made a lib to write commands (like cobra or urfave/cli), but based entirely on the `flag` package: https://github.com/Thiht/go-command

Nice CLI lib ! I'm still looking for a Argh or Typer equivalent though.

Re: Some Go web dev notes

#115

Post by miki123211 »

mewpmewp2 wrote: post #110
arp242 wrote: post #59

Earlier quoted context omitted.

I've picked up some Go projects after no development for years, including some I didn't write myself as a contractor. It's typically been a fairly painless experience. Typically dependencies go from "1.3.1" to "1.7.5" or something, and generally it's a "read changelogs, nothing interesting, updating just works"-type experience. On the frontend side it's typically been much more difficult. There are tons of dependenci…

Arguably it's just the frontend. You can use old node in backend as much as you please. Frontend UI expectations evolve so quickly while APIs & backend can just stay the same, if it works it works.

> You can use old node in backend as much as you please.

Not really, or at least not always.

I once tried to run some old Node project on Apple Silicon. It relied on some package that wanted to download binaries, but that ancient version didn't support Apple Silicon yet. Upgrading the package to an Apple Silicon supporting version required updating half of the other dependencies, and that broke everything. Eventually, I just gave up.

Re: Some Go web dev notes

#116

Post by wg0 »

For application development - Go is underrated. And heavily. I say this coming from Python which is really great but I like the go's damn simplicity more which is reflected everywhere.

What makes me happy is that lots of critical infrastructure tooling is also in Go from datbases to web servers and cluster orchestrators.

Re: Some Go web dev notes

#117

Post by zerr »

Are the any "fronty" back-end (or straight client/desktop) jobs using Go? i.e. I'd like to use Go on the job but all I see is AWS/Kubernetes/mix-of-DevOps kind of positions.

Re: Some Go web dev notes

#118

Post by arp242 »

kbolino wrote: post #77
arp242 wrote: post #60

Earlier quoted context omitted.

stdlib templates are a bit idiosyncratic and probably not the easiest to start with, but they do work and don't have "weird issues" AFAIK. What issues did you encounter?

I don't know what issues others have had with it, but for me one notable thing is that html/template strips all comments out. This is by design, but it's not documented anywhere. I've proposed making this configurable, but my proposal has gotten no traction so far.

https://github.com/golang/go/issues/54380

I didn't know about that. I agree it qualifies as a "weird issue".

Re: Some Go web dev notes

#119

Post by arp242 »

mewpmewp2 wrote: post #110
arp242 wrote: post #59

Earlier quoted context omitted.

I've picked up some Go projects after no development for years, including some I didn't write myself as a contractor. It's typically been a fairly painless experience. Typically dependencies go from "1.3.1" to "1.7.5" or something, and generally it's a "read changelogs, nothing interesting, updating just works"-type experience. On the frontend side it's typically been much more difficult. There are tons of dependenci…

Arguably it's just the frontend. You can use old node in backend as much as you please. Frontend UI expectations evolve so quickly while APIs & backend can just stay the same, if it works it works.

It's not just "old node", it's also "old webpack" and "old vuejs" and "old everything". Yes, "it works" and strictly you don't really need to update it, but you're going to add a lot of friction down the line by never updating and at some point the situation will become untenable.

Re: Some Go web dev notes

#120

Post by mewpmewp2 »

arp242 wrote: post #119
mewpmewp2 wrote: post #110

Earlier quoted context omitted.

Arguably it's just the frontend. You can use old node in backend as much as you please. Frontend UI expectations evolve so quickly while APIs & backend can just stay the same, if it works it works.

It's not just "old node", it's also "old webpack" and "old vuejs" and "old everything". Yes, "it works" and strictly you don't really need to update it, but you're going to add a lot of friction down the line by never updating and at some point the situation will become untenable.

Old webpack and vuejs yes, because it's the UI which does get quickly old, but APIs or also things you would do with Go don't really have to change much as time goes on. A simple Express server and that's it.
Post reply on HN