How we're trying to make our PHP devs efficient also with Golang

For the quick background presentation (👋), I'm a backend / platform engineer, I work in a company with a monolithic PHP (Laravel) main application.

We're in the journey to split it in smaller services or to move some recurring logic as sidecars. And for this, we noticed that the best choice was not always PHP, but sometimes Golang was more appropriate for our use cases.

The main problems we faced:

• Since our company devs are mostly all PHP devs, we needed a way to ramp them up on Golang.
• We also needed to avoid to have too much differences in the Go code produced by different teams, and their code to have the same conventions when it comes to our platform compatibility (same way to log, same way to handle env vars / config, same way to handle traces / metrics, etc...)

We (platform team) worked and iterated on some Go app skeletons, pre-configuring some libs, applying some shared conventions, and with time it became consequent enough that we considered to open source it.

So I present to you Yokai 🚀
It's a simple, modular and observable Go framework for backend applications.

It comes with a bunch of features (that we needed on our own production projects): HTTP server, gRPC server, workers, database instrumentation, etc ... while always keeping a strong focus on observability (logs, traces, metrics). Everything is in the docs if you want to know more about it.

So, if you're coming from a PHP framework background (like Symfony, Laravel) and want to start exploring Go, this offers you something close to what you're used to: dependency injection, observability, easy ways to test, etc ... but for Go :)

Feel free to take a look (docs & demo apps), to comment, and happy coding 👍

Check Yokai on GitHub.

Comments

[Ezpie]

I See, your engineers are mainly PHP devs... hey you all own lambos!

[Jonathan VUILLEMIN]

We wish 😁

[david duymelinck]

Why not goravel, when you biggest application is laravel?

[Jonathan VUILLEMIN]

Cause we have a strong requirement on observability (logs, traces, metrics) that goravel doesn't provide. And we wanted to avoid ORM usage (goravel decorates GORM afaik).

All in all, we wanted something tailormade, but close to Go idioms and generic enough to be re-usable in our different projects (and finally open sourced).