[thanzex]

Hi! While the project does look very interesting, i'm kind of put off by the code. While it is pretty organized and neat, I can see that all of the services offered are hard-coded. Like the 330 lines long if-else chain in apps/api/src/lib/services/common.ts.

This way every time you need to set add a new service to coolify there's the need to ship a new version.

Why did you choose to go this way rather than a more generalized concept of a service? Wouldn't having a generic service architecture be more maintainable and ( imo ) more importantly add the capability to have a dynamic, global and customizable 'app store' of sort?

[thatwasunusual]

> i'm kind of put off by the code. While it is pretty organized and neat, I can see that all of the services offered are hard-coded. Like the 330 lines long if-else chain in apps/api/src/lib/services/common.ts.

I agree and disagree.

I agree that this kind of approach to coding is something that would put anyone senior-ish off totally, but I disagree at the same time because it's only 20-ish services, and the code is easily refactorable.

My assumption - after having read code 30+ years - is that this is done on purpose, so that they want to stabilise the approach and refactor it later. Though, as we all know, there's no thing as "I'll fix this later" in programming, but still (in this case) not something that would put me off.

Also, it's on github, so I could always refactor it for them if I'm not happy with it.

[gbro3n]

This isn't such a sin for a young project like this - Making code configurable adds overhead and it's often right to avoid 'over-configuration' along with 'over-abstraction' and other 'over-optimization efforts'. What is important is to isolate functions for orthogonality which will allow a project to be refactored according to priority needs further down the line.

[andrasbacsai]

The reason, I (founder of Coolify) choose that, it was faster.

I’m currently making a feature, that will change this. All services could be defined with a simple yaml file that won’t be hardcoded. They will be sitting in a repository and everyone can add any service with a simple yaml file.

It is definitely more maintainable than the current solution, but with the current solution, I could iterate faster. :)

[datavirtue]

Death to yaml. Thank you.

[nonethewiser]

> Like the 330 lines long if-else chain in apps/api/src/lib/services/common.ts.

As far as I can see, there is no 330 line long if-else chain in that file. Nothing even close to it. Can you link to what you're talking about more specifically?