I talk about dependencies management in Go. How to keep your dependencies up-to-date and how to check if there's any updates available. What to do when a package change their major version.
List all packages and latest versions:
$ go list -m -u all
Update all packages to their latest minor versions:
$ go get -u ./...
If you'd like to support this podcast consider buying a copy of my course Build SaaS apps in Go.
I was toying with the idea of using WebAssembly runner as a plugin / extension mechanism from a Go (host) program to extend the capabilities of a program at runtime.
Let's talk about Go's concurrency. It's a powerful tool to have at your disposal but a hard one to master and use correctly.
If you want to support the pod the best way is to purchase my course (thanks).
At beginning I was deploying my Go servers to a DigitalOcean droplet. But for the last 3 years I'm enjoying Render, which listen to my git push and automatically deploy app for me in a blue-green deployment.
If you enjoy my podcast have a look at the following:
I recently created an exportable Go package from StaticBackend, an open source backend API which was self-hosted.
I ended up using the internal package way to heavily and this design decision bite me when I decided to create an exportable package. Now all things that needed to be expose that was in the internal package had to be refactored into their own packages.
Links:
Usage of -ldflags:
go build -ldflags "-X main.varName=from_build" -o mycli
Inside your code:
var varName string
func main() {
fmt.Println(varName) // prints "from_build"
}
Here's what I'm using for StaticBackend -v flag:
go build -ldflags \
"-X github.com/staticbackendhq/core/config.BuildTime=$(shell date +'%Y-%m-%d.%H:%M:%S') \
-X github.com/staticbackendhq/core/config.CommitHash=$(shell git log --pretty=format:'%h' -n 1) \
-X github.com/staticbackendhq/core/config.Version=$(shell git describe --tags)" \
-o staticbackend
Links:
If you'd like to join the dev of StaticBackend a Firebase alternative I'm building in Go you're welcome, there's a discord if you'd want to chat. https://github.com/staticbackendhq/core
If you'd like to checkout my course called Build SaaS apps in Go or want to support this show, that's the best way.
If you're on Twitter make sure to follow me: https://twitter.com/dominicstpierre
sqlx: https://github.com/jmoiron/sqlx
sqlboiler: https://github.com/volatiletech/sqlboiler
If you're looking to learn how to build web API with Go, checkout my course on building SaaS in Go.
I've been maintaining 20 years old systems for a long time now. I've been working with legacy applications in .NET. To me Go has some great advantages built-in by design that should help in 10-15 years from now when the applications that are created today will be on maintenance mode.
What are you thinking about Generics? What about 3rd party libraries that will pop from everywhere once Go 1.18 launched?
Personally, I'll appreciate what the std lib offers and will wait before writing generics code, making sure I really need it.
I'm currently working on a free and open-source self-hosted Firebase alternative - if such things sound interesting, please join the Discord group and contribution are very welcome (it's written in Go of course).
This is my course on Building SaaS apps in Go.
If you'd like to check the code, the PR is still active.
StaticBackend repo: https://github.com/staticbackendhq/core
My course on Building SaaS in go
Share episode topic idea with me on Twitter @dominicstpierre
We go over what are pointers and when to use or not use them. For instance, this is probably not a good use for pointers.
func main() {
var i int = 10
abc(&i)
}
func abc(i int) {
i = 15
}
In my opinion any dereferencing is probably bad. Better way:
func main() {
var i int = 10
i = abc(i)
}
func abc(i int) int {
return 15
}
I also try to give some basics info regarding the stack and heap and why pointers might not be seen as an optimization.
I have a course on building SaaS in Go.
Follow me on Twitter.
Don't stress too much about having the "proper" project structure to the point where you might over-engineer or be paralyzed by the thought of doing something wrong.
It's just hard, and even 5+ years of Go experience will not ensure you're creating the optimal packages and structure. It's an art mixed with preferences that become a little easier with time but remain challenging.
I wrote a getting started with Go guide that cover a little about project structure and how to get started with Go.
If you're in writing web applications and maybe even SaaS, I have a course on creating API-first SaaS with Go.
Example of not using the happy path at 1st indentation:
try {
if (user.HasAccessTo(Admin) {
if (somethingElse()) {
// happy path
}
else {}
}
else {}
}
catch(Exception ex) {
// what really happened, and where?
}An example of happy path in idiomatic Go:
ok, error := hasAccessTo(user, ADMIN)
if err != nil || !ok {
// handle not access
}if !somethingElse() {
// handle something else false
}
// Happy path
My course on building SaaS apps in Go.