Potentially open sourcing Swift Dependency injection solution

Hi:

Two years ago Google began developing Syringe, a Swifty Dagger 2-like compile-time dependency injection solution for iOS and Swift. It uses SourceKit to analyze your application and generates wire-up code to tie classes/structures together via initializer injection.

We realize there are other offerings, such as Needle, Cleanse, Weaver and some run-time injection solutions but we built our solution as we felt the performance requirements of large dependency graphs, module support and compile time validation were key requirements for us. When we made the decision to create our solution 2 years ago Cleanse did not appear to have further active development and Needle hadn't been released yet.

Fast forward to today and we have stopped development on Syringe. The demand for such a solution within Google is not materializing as fast as expected even though Syringe is reasonably feature complete if not product complete. We are exploring open sourcing it, but not because we want everyone to use it immediately or that we'll be deeply committed to creating a community around it. Rather we believe there are some novel insights about doing DI in Swift in a truly Swift-y way, including working across modules, multibinding/optional binding and namespace collision solutions, that may help other offerings.

We, Google, are sensitive to our history of open sourcing of things that we have not supported as fully as one would expect. We also do have a history of doing the opposite (Angular, Firebase, etc), but are reluctant to see this project as just another example of the former. The last thing we want to do is have the community conclude ‘Google released it, they must be fully behind it, but they’re not and I’ve already decided to adopt it. Damn you Google’ If there is sufficient interest/demand to use it for what it is, an example of how DI can be done in Swift, we will release it but need some level of input from the community that that would be desirable before doing so. Please provide your feedback on such an approach.

11 Likes

Would you be able to provide a sort of comparison between your solution and the existing solutions so that we could get a better understanding of how it compares? I think that would be pretty useful in determining whether people would be willing to switch over and adopt Syringe.

If anything, I think being able to see the approaches you guys have taken could be valuable to the community as a whole.

We can, but we are not proposing people switch to Syringe. We are explicitly trying to avoid that. Rather we would release it so authors of other DI frameworks may find use of its solutions for their DI solutions.

If that’s the case, then the open source version of this should be made very clear that it isn’t meant for adoption and is merely an example into techniques that can be applied to other DI solutions.

If it’s very clear to anyone coming across the framework that it isn’t meant for adoption, and no promises of support, I don’t see much harm in tossing the code into the open for people to gaze into.

regardless of how clearly thats communicated, it may still get misunderstood and cause reputational harm in the long run. However we're willing to take that risk if the upside to other DI authors outweighs that risk. So this thread is an attempt at evaluating the upside appetite so we can make an open sourcing decision.

Hello! I'm the co-author of Needle at Uber. It's great to see that Google has also created its own solution for DI. I'd love to see what we can use to improve Needle.

Here at Uber, we created Needle after evaluating all the existing open source solutions, including the ones you had mentioned. Some of them are not compile-time safe. Others cannot scale to our codebase's size. We have over 3 million lines of Swift code here at Uber.

I agree with your sentiment completely. Perhaps instead of releasing Syringe as yet another solution, you can work with us to improve Needle? I'd love to collaborate on this. I'm definitely biased. But IMHO, in terms of compile-time safety, ease of use, scalability, and performance, I believe Needle has the best chance of becoming the standard DI system for Swift. And since Uber has fully adopted Needle for its over 3M lines of Swift codebase, we have the entire mobile infrastructure team fully behind it forever.

1 Like

I have two thoughts... three thoughts?... No; two thoughts and a comment.

First, what about releasing Syringe under a license that allows people or organizations to freely copy its ideas and algorithms into their own projects, but not its actual code? Realistically, I doubt there's a way to prove anyone violated the license, or that you could do much about it if they did. However, the point (as I understand it) is to put up bright, flashing, neon warning signs, not to actually prevent people from using Syringe if they're fully aware of what they're getting into and feel it's a good solution for them anyway.

Second, instead of releasing it on Google's GitHub or Gitlab or Whatever account, could you create separate account called "Projects Which Didn't Quite Work Out and Aren't Supported or Under Any Kind of Development Anymore (Active or Inactive) But We Don't Want to Just Delete Because They Have Some Cool Ideas"? I mean, if someone sees that as the account name and decides to depend on one of those repos anyway, that's on them. Plus, it wouldn't say "Google" anywhere (except maybe in copyright notices at the top of all the files). Furthermore, for anyone at Google (or anyone else you want to let in) that account could become, um, "a safe and peaceful resting place for projects whose light didn't quite shine long enough to brighten the world", and which probably have worth or interest to someone, just not the organization that started them. Having a pseudo-curated list of that kind of project might kick off another open-source renaissance, as potentially millions of developers start looking through the code to see what makes any given project interesting enough to not delete even though it didn't do what it was supposed to do. I mean, probably not, but the optimist in me wants to believe :grin:

Lastly, speaking personally, even if nothing comes of it in this particular case, thanks for asking. I appreciate Google's willingness to think outside the box WRT what to do with internal projects that simply didn't end up meeting their needs well enough to finish developing, and I wish more companies would at least ask the question.

1 Like

Hi! I'm the author of Weaver at Scribd which seems to be pretty similar to what you have been working on at Google with Syringe.

I would love to hear more about why Syringe didn't workout for you. I have been developing Weaver as an experiment at first, just to see if I could build something with a "do everything at compile-time" rule, and it worked out pretty well. We now have to start adopting it more widely at Scribd and improve it in term of scalability. Knowing the reasons why such an idea didn't work out as expected at Google would definitely help.

Also, I'm very curious to see what solution you came up to at Google and would be interested in partnering to build a solid and accessible DI tool by using both our work on the topic.

Terms of Service

Privacy Policy

Cookie Policy