Last summer I’ve announced the «Composer Cloud Resolver» which we have been using ever since to let our Contao users install their Composer dependencies directly on their webservers using our GUI called «Contao Manager». If you haven’t read this article, I strongly recommend you do so now as you’ll lack context to understand this post otherwise.
Due to the absence of proper metrics (and the dedication to privacy protection) I cannot comment on how many jobs the Resolver has processed up until now but I can assure you it’s in the thousands and it turned out to work super stable for us. 🎉
During last summer’s announcement I also wrote that I’m not sure if I want to open source it because of numerous reasons. However, I’ve also stated that I’m very open to help other Open Source projects and make sure they can benefit from our efforts as well. We’ve since been approached by different people of various projects such as Joomla!, Wordpress and TYPO3 which indeed shows that they have similar issues as we had for Contao.
So, I asked myself what I could do and today, I’d like to present the «Composer Resolver Cloud»!
I’ve switched the order of the words «Resolver» and «Cloud» because it’s really a cloud now 😃. In fact, it’s still based on the same code so technically speaking we’re talking about version 2.
So what’s new then?
- First off, it now has a simple website explaining all you need to know about it: https://composer-resolver.cloud
- It’s now multi-tenant capable, allowing us to provide dedicated workers for whomever is interested in using it!
- There’s a «public» tenant/client key limited in queuing ability but allowing you to test your integrations and play with the API to see if it could help you solve your problem. For free!
- There’s an OpenAPI 3.0 spec now for you developers out there!
- It now supports local packages and is thus able to resolve «path» and «artifact» repositories if you send the package information of those along when creating a job!
- We now collect basic metrics. All the metrics that are captured (yes, every single one of them!) and their respective reason why they are collected are listed on the website. Basically they allow us to make infrastructure decisions and maybe they might also help project maintainers to make their decisions (e.g. «which PHP version is used the most to resolve?»). None of the information is expressed as chart yet but at least I might be able to introduce such a feature in the future.
Unfortunately, running workers that need that much memory is a pretty cost-intensive task and as much as we love all you folks working on Open Source projects, we just simply cannot afford to bear the costs for everyone 😄
The idea is that once you decided the «Composer Resolver Cloud» is your way to go, you get in touch with us to get your own «client key». As of today, there’s absolutely no pricing concept yet and we need to figure out the best way with the first one of you. Nobody is really interested in making money with this project but the «Contao Association» financed quite a big deal of the initial development and so there might be some constraints there.
Anyways, I’m super happy with the way it turned out to work for our customers who use Contao and the whole Contao community itself.
From a simple idea in 2016 to a pretty solid solution, what a ride! 🎉 🏁