dagger-examples
Dagger2
dagger-examples | Dagger2 | |
---|---|---|
2 | 50 | |
13 | 17,317 | |
- | 0.2% | |
10.0 | 9.1 | |
over 1 year ago | 6 days ago | |
Python | Java | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dagger-examples
-
Dagger Python SDK: Develop Your CI/CD Pipelines as Code
> A) Why async in the user code? Is it really necessary?
It's not a requirement, but it's simpler to default to one and mention the other. You can see an example of sync code in https://github.com/helderco/dagger-examples/blob/main/say_sy... and we'll add a guide in the docs website to explain the difference.
Why async?
It's more inclusive. If you want to run dagger from an async environment (say FastAPI), you don't want to run blocking code. You can run the whole pipeline in a thread, but not really taking advantage of the event loop. It's simpler to do the opposite because if you run in a sync environment (like all our examples, running from CLI), it's much easier to just spin an event loop with `anyio.run`.
It's more powerful. For most examples probably the difference is small, unless you're using a lot of async features. Just remove async/await keywords and the event loop. But you can easily reach for concurrency if there's benefit. While the dagger engine ensures most of the parallelism and efficiency, some pipelines can benefit from doing this at the language level. See this example where I'm testing a library (FastAPI) with multiple Python versions: https://github.com/helderco/dagger-examples/blob/main/test_c.... It has an obvious performance benefit compared to running "synchronously": https://github.com/helderco/dagger-examples/blob/main/test_m...
Dagger has a client and a server architecture, so you're sending requests through the network. This is an especially common use case for using async.
Async Python is on the rise. More and more libraries are supporting it, more users are getting to know it, and sometimes it feels very transitional. It's very hard to maintain both async and sync code. There's a lot of duplication because you need blocking and non-blocking versions for a lot of things like network requests, file operations and running subprocesses. But I've made quite an effort to support both and meet you where you're at. I especially took great care to hide the sync/async classes and methods behind common names so it's easy to change from one to another.
I'm very interested to know the community's adoption or preference of one vs the other. :)
Dagger2
- Dagger 2.49 (KSP, @AssistedInject with @HiltViewModel, more)
- Dagger 2.48 adds alpha KSP support
- Dagger KSP update & Breaking changes required to use Dagger KSP
-
Performance and memory impact of the @Singleton annotation in Dagger
There used to be a thing called "releasable references" which was that. It was removed, though: https://github.com/google/dagger/issues/1117
-
Dependency injection with AWS Lambdas in java
As said in the title, we will focus on the dependency inversion principle and one of its application : dependency injection. For production-ready applications, it would be better to rely on a framework and not implement its own container. For it, the java ecosystem have 3 frameworks available : Spring, Guice and Dagger.
-
Refactoring our Dependency Injection using Anvil
At Reddit, we use Dagger 2 for handling dependency injection (DI) in our Android application. As we’ve scaled the application over the years, we’ve accrued a bit of technical debt in how we have approached this problem.
-
Dagger Python SDK: Develop Your CI/CD Pipelines as Code
Confusing. I initially thought someone ported the Dagger DI framework to Python: https://dagger.dev/
-
Multiplatform dependency injection libraries equivalent to Dagger/Anvil
I'm currently using Dagger and Anvil for my DI needs. It's been working really well, especially around what Anvil permits in terms of multibindings defined on the type declaration rather than in a module. For example:
-
Dagger 2.43 released with support for multiple instances of the same ViewModel using keys 🎉
Great job, I have been waiting for this feature/fix for a long time https://github.com/google/dagger/issues/2328
-
Best libraries for Android Developers
Dagger
What are some alternatives?
dagger - Application Delivery as Code that Runs Anywhere
Guice - Guice (pronounced 'juice') is a lightweight dependency injection framework for Java 11 and above, brought to you by Google.
dagster - An orchestration platform for the development, production, and observation of data assets.
Toothpick - A scope tree based Dependency Injection (DI) library for Java / Kotlin / Android.
Weld - Weld, including integrations for Servlet containers and Java SE, examples and documentation
butterknife - Bind Android views and callbacks to fields and methods.
HK2
Dynamic CDI - Dynamic Context Dependency Injection
Apache DeltaSpike - Mirror of Apache Deltaspike
Feather - Lightweight dependency injection for Java and Android (JSR-330)
Tiger
Katana - Lightweight, minimalistic dependency injection library for Kotlin & Android