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

71–80 of 154 posts

Re: Some Go web dev notes

#71

Post by ncruces »

If you decide to use SQLite with one (single thread) writer pool and an other reader pool, this may help: https://github.com/bxcodec/dbresolver

Also sometimes if I have two tables where I know I’ll never need to do a JOIN between them, I’ll just put them in separate databases so that I can connect to them independently.

If this data belongs together and you're just doing this to improve concurrency, this may be a case where BEGIN CONCURRENT helps: https://sqlite.org/src/doc/begin-concurrent/doc/begin_concur...

If you want to experiment with BEGIN CONCURRENT in Go you could do worse than try my SQLite driver: https://github.com/ncruces/go-sqlite3

Import this package to get the version with BEGIN CONCURRENT: https://github.com/ncruces/go-sqlite3/tree/main/embed/bcw2

Re: Some Go web dev notes

#72

Post by CBarkleyU »

0x_rs wrote: post #58
imiric wrote: post #29

There are some good tips here. As for sqlc, I really wanted to like it, but it had some major limitations and minor annoyances last time I tried it a few months ago. You might want to go through its list of issues[1] before adopting it. Things like no support for dynamic queries[2], one-to-many relationships[3], embedded CTEs[4], composite types[5], etc. It might work fine if you only have simple needs, but if you ev…

It gets mentioned a lot in the context of database/sql and sqlc, but Jet has been a great alternative so far, most notably because of its non-issue with dynamic queries support. https://github.com/go-jet/jet/

Unfortunately it relies on CGO for SQLite, which is a bummer

Re: Some Go web dev notes

#73

Post by marcosdumay »

gwd wrote: post #20

> I learned the hard way that if I don’t do this then I’ll get SQLITE_BUSY errors from two threads trying to write to the db at the same time. OK, here's a potentially controversial opinion from someone coming into the web + DB field from writing operating systems: 1. Database transactions are designed to fail Therefore 2. All database transactions should done in a transaction loop Basically something like this: http…

You shouldn't blindly retry things that fail as a default, and you should really not default into making the decision of what to do on a server that is just on the middle between the actual user and the database.

Handling errors on the middle is a dangerous optimization.

Re: Some Go web dev notes

#74

Post by arccy »

physicles wrote: post #8

GOMEMLIMIT has really cut down on the amount of time I’ve had to spend worrying about the GC. I’d recommend it. Plus, if you’re using kubernetes or docker, you can automatically set it to the orchestrator-managed memory limit using something like https://github.com/KimMachineGun/automemlimit — no need to add any manual config at all.

https://pkg.go.dev/go.uber.org/automaxprocs is another useful one if you set CPU limits

Re: Some Go web dev notes

#75

Post by arccy »

NAHWheatCracker wrote: post #70
coffeeindex wrote: post #53

Earlier quoted context omitted.

I believe it is recommended to not use gobin/gopath anymore. go test ./… tests all files in the project, so I assume build does something similar.

My experience with go build ./... is that it compiles everything but it doesn't make the binaries. > When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built. From https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependenc... A bit annoying when you want to build a bunch of executables, but it…

  go build -o some/dir/ ./...
will actually output the binaries

Re: Some Go web dev notes

#76

Post by ncruces »

CBarkleyU wrote: post #72
0x_rs wrote: post #58

Earlier quoted context omitted.

It gets mentioned a lot in the context of database/sql and sqlc, but Jet has been a great alternative so far, most notably because of its non-issue with dynamic queries support. https://github.com/go-jet/jet/

Unfortunately it relies on CGO for SQLite, which is a bummer

Yeah, it'd be much nicer if libraries were designed to be driver agnostic, like redka which supports 4 different SQLite drivers:

https://github.com/nalgeon/redka/tree/main/example

Re: Some Go web dev notes

#77

Post by kbolino »

arp242 wrote: post #60
trustno2 wrote: post #56

Other note Sooner or later you will hit html/template, and realize it's actually very weird and has a lot of weird issues. Don't use html/template. I grew to like Templ instead

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.

Re: Some Go web dev notes

#78

Post by NAHWheatCracker »

arccy wrote: post #75
NAHWheatCracker wrote: post #70

Earlier quoted context omitted.

My experience with go build ./... is that it compiles everything but it doesn't make the binaries. > When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built. From https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependenc... A bit annoying when you want to build a bunch of executables, but it…

go build -o some/dir/ ./... will actually output the binaries

Sick, I couldn't figure it out when I needed it so I just manually created a 20 line script to cd into each directory and go build.

Re: Some Go web dev notes

#79

Post by sethammons »

trustno2 wrote: post #56

Other note Sooner or later you will hit html/template, and realize it's actually very weird and has a lot of weird issues. Don't use html/template. I grew to like Templ instead

I am just trying Templ. I like what I am seeing for the most part. There are some tooling ergonomics to work out. Lots of "suddenly the editor things everything is an error and nothing will autoimport or format" back to mostly working. Click to definition goes to the autogenerated code instead of the templ file. Couple things like that. But soooooooooo much better to deal with code gen than html/template. That thing is a pita

Re: Some Go web dev notes

#80

Post by 0x_rs »

CBarkleyU wrote: post #72
0x_rs wrote: post #58

Earlier quoted context omitted.

It gets mentioned a lot in the context of database/sql and sqlc, but Jet has been a great alternative so far, most notably because of its non-issue with dynamic queries support. https://github.com/go-jet/jet/

Unfortunately it relies on CGO for SQLite, which is a bummer

Good point. The generator (and tests) do use mattn's SQLite driver, but you're free to choose any database/sql-compliant implementation in your program, so that means setting up the necessary toolchain only in your development machine, even just using a very simple zig setup. I think it should be fairly easy to make it use a pure-go driver, some of which are nearly drop-in replacements and have only minute differences like the string name being "sqlite" instead of "sqlite3", but of course that's extra stuff to test and maintain (but still only running when you're generating from a target database).
Post reply on HN