Trying Another Way... (Dependency Injection)

NOTE: Before or after watching this video I HIGHLY recommend you read over the FX documentation. FX is weird, and while a video will help you get the idea of what it does, nothing can replace actually doing it. It is a stupidly useful package, but its up to you to learn it!

This video goes over an example of how one could structure a GoLang backend. This is not the only way to do it, nor is it objectively the best way to do it, but it does solve the problem. This is part of the ongoing SvelteKit + GoLang series.

🚀 DEPLOY YOUR BACKENDS 🚀

My Socials

My Companies

#golang #programming #engineering

[catalinim]

tech school has a really good series on microservices. I use that structure for all my go projects

[duongphuhiep]

Greate video, I didn't know this Fx library until now. As a C# developer. I remark a difference between this "Go Fx/DI" and "C#/DI".

In C#, Java, we also use the DI framework to manage the "objects life cycle". For eg, when you "register" (or "provide") a "NewUserStorage", you will have to declare the "life time scope" of the "UserStorage" object after it is created. In C# the life time can be "singleton", "scoped" or "transient".

* When you provide(NewUserStorage, "singleton") then the NewUserStorage() function would be called only once, then the created object "UserStorage" is re-use until the end of the application.
* When you provide(NewUserStorage, "transient") then the NewUserStorage() function would be called each time a consumer need to resolve a "UserStorage"

The Fx docs did not mention what is the life time scope of the provided object (I suspect that they are all transient?..)

[arthuralvespsy]

Hey Ben first of all, thank you about the video, I had some experience using the FX and for the specific project that I was working this looked like a Bazooka because behind the scenes it's using signals in a pool of objects inside the Context.

[coffeeintocode]

Nice 👌 never seen FX in use actually. Agreed though, lack of convention/opinion in Go is both a blessing and a curse

[anselminos]

been using fx for a few months, i think it is great for dependency injection, although i wish it wouldn't log as much as it does by default.

[jeheskielsunloy]

hey nice video mate, I was just wondering what is your vscode theme? i kinda like it

[manee]

Thanks which software you use for drawing ? I mean the online app that can write like handwriting :)

[JohnDoe-jizv]

Been using this for quite some time, and I would say that’s the way to scaffold servers or anything else in golang. Uberfx ftw

[주영이-xy]

nice video :)
I have a career in Python and Java, and I honestly prefer the DI (Dependency Injection) pattern.
Recently, I've been studying Go and it seems there's a lot of discussion about the DI pattern in the Go community.
I have a question regarding this.
When using frameworks or libraries that support the DI pattern in runtime environments like fx, dig, as far as I know, it involves using reflection, which I heard is an expensive resource in Go. I'm curious about what advantages you've gained using fx, compared to the aforementioned disadvantages.

[josephmartin]

You earned a sub man, thanks alot and please whats the name of the vscode font please, thank you!

[DevlogBill]

Hi Ben, I have question? What backend technology would you recommend for me? I am from NYC so I have a good selection. I have about 1 year and a half experience in programming. Did 8 months in web development with HTML, CSS and JavaScript and very little experience with React. But I also have experience with Django and I am already making API's and I made 2 CRUD apps. But I am thinking about switching from Django to something else, there are hardly no jobs for Django. I check on indeed and I only see 2 or 8 jobs tops on a good day.
Is Golang easy to pick up? I am assuming if I have already some very basic skills in a backend framework I hope learning another backend framework or library won't be as difficult.
I would appreciate any recommendations, thank you.

[esserk]

do not use fx, please no. Dependency injection is a terrible idea.
It breaks golang in so many ways.
First you lose the compile time dependency checks, so it might compile and still not run.
You might have code that is not even used. Go would usually catch that because you’d be initialising something and not using it. With fx you also lose that.
Everything is a singleton, so to instantiate more than one object of the same type you have to wrap it in some bullshit..
You totally lose sight of where your dependencies are coming from for your other constructors.
I think it’s embarrassing for uber to put their name behind this shitty library.

Just use plain go if possible. So much easier to just walk through your entrypoints, just a map from URL to handler and you build the app from there.. simple