A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Again. WHY DO YOU KEEP BRINGING UP LINES OF CODE AS A METRIC OF USEFULNESS??
About half of HashiCorp Vault's code is unit, system, and integration tests.
They thoroughly test the front-end and the back-end. And to take it a step forward they have end-to-end tests and acceptance tests.
Tests written to avoid these "vulnerbilities" that you keep preaching have multiple lines of code create.
Ok then you can write a config server yourself if you are scared of vulernerbilities. While you are at it MySQL has a vulnerbility back in May so you might want to write your own database engine while your at it.
Also, Chrome just recently had a vulnerbility too. Don't forget to build a while web browser as well. Actually, Dev.to has a bug page, yikes you might wanna re-write this website too.
I mentioned in the article that config servers are usually accessed form VPCs so even if one of those "hundreds of dependencies" has a bug, the config server is protected from the internet.
Also I find what your saying kinda funny.
If a project uses tons of dependencies, then the project is bad. Instead, if they write the features by hand which increases the lines of code, that also makes the project bad.
You really need to read what others' saying before replying completely irrelevant things. If I just need to store 1k of data, I'll not use MySQL, I'll just use a JSON file. If I just want to download a file, I'll not use Chrome, I'll just use curl or wget. You must have some serious problems with your eyes IF you can't properly read what others write.
I clearly said those handful of pain points you mentioned in your post does NOT require those enormous "config servers" to address. Those are some simple goals achievable with some very simple config management solutions based on config files, or if you want, with centralized databases, which may take even less time and easier to implement than deploying and adapting to one of those "config servers" mentioned in your post. If you want to call such simple config management solutions "config servers" too, fine. I guess you can call both koa and Spring as "web frameworks", but their differences are huge.
Like I said, using one of those enormous "config servers" to address those pain points mentioned in your post is like deploying an entire Spring Cloud infrastructure to just serve a simple website with features that can be done by using just koa and a handful simple self-made middlewares. Yes you can try deploy a complete Spring Cloud stack to just serve a simple website, but it will take more time, use more resources, and exposed to more potential vulnerabilities UNNECESSARILY, so noone would recommend that.
When you can address all your pain points regarding dotenv files with some simple bespoke solution of several hundreds lines of code, deploying and adapting to an enormous "config server" mentioned in your post to achieve the same goals is really not something to recommend.
Next time try really read and understand what others have said first.
===
You seem to really have some serious problems with your eyes, or your English comprehension skills. What I said is that achieving the same goals with less code is good, and if by orders of magnitude less amount of code, then that's really really good. More dependencies usually means more code in total to achieve your goals.
And about the lines of code as a useful measurement, yes they are when the differences are ORDERS OF MAGNITUDE kind of huge. A simple "Hello World" program practically has zero bug (of course it has next to nil functionality too), 600k lines of code may not differ from 500k lines of code much in terms of complexity and potential bugginess, but if THE SAME GOALS can be achieved by 600 lines of code instead of 600k lines of code, that's some big difference.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
I don't think we are going to get anywhere, we are clearly at a disconnect and throwing insults isn't going to solve much. Let's just agree to meet in the middle on this.
no insults, just curious, is English your first language? I kinda understand what you are trying to say with "agree to meet in the middle" here, but that sounds really a little odd here, just saying.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Yes english is my first langauge. What i mean by meet in the middle, I'm saying we both respectfully acknowledge the other person side and agree to disagree.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Again. WHY DO YOU KEEP BRINGING UP LINES OF CODE AS A METRIC OF USEFULNESS??
About half of HashiCorp Vault's code is unit, system, and integration tests.
They thoroughly test the front-end and the back-end. And to take it a step forward they have end-to-end tests and acceptance tests.
Tests written to avoid these "vulnerbilities" that you keep preaching have multiple lines of code create.
Ok then you can write a config server yourself if you are scared of vulernerbilities. While you are at it MySQL has a vulnerbility back in May so you might want to write your own database engine while your at it.
Also, Chrome just recently had a vulnerbility too. Don't forget to build a while web browser as well. Actually, Dev.to has a bug page, yikes you might wanna re-write this website too.
I mentioned in the article that config servers are usually accessed form VPCs so even if one of those "hundreds of dependencies" has a bug, the config server is protected from the internet.
Also I find what your saying kinda funny.
If a project uses tons of dependencies, then the project is bad. Instead, if they write the features by hand which increases the lines of code, that also makes the project bad.
You really need to read what others' saying before replying completely irrelevant things. If I just need to store 1k of data, I'll not use MySQL, I'll just use a JSON file. If I just want to download a file, I'll not use Chrome, I'll just use curl or wget. You must have some serious problems with your eyes IF you can't properly read what others write.
I clearly said those handful of pain points you mentioned in your post does NOT require those enormous "config servers" to address. Those are some simple goals achievable with some very simple config management solutions based on config files, or if you want, with centralized databases, which may take even less time and easier to implement than deploying and adapting to one of those "config servers" mentioned in your post. If you want to call such simple config management solutions "config servers" too, fine. I guess you can call both koa and Spring as "web frameworks", but their differences are huge.
Like I said, using one of those enormous "config servers" to address those pain points mentioned in your post is like deploying an entire Spring Cloud infrastructure to just serve a simple website with features that can be done by using just koa and a handful simple self-made middlewares. Yes you can try deploy a complete Spring Cloud stack to just serve a simple website, but it will take more time, use more resources, and exposed to more potential vulnerabilities UNNECESSARILY, so noone would recommend that.
When you can address all your pain points regarding dotenv files with some simple bespoke solution of several hundreds lines of code, deploying and adapting to an enormous "config server" mentioned in your post to achieve the same goals is really not something to recommend.
Next time try really read and understand what others have said first.
===
You seem to really have some serious problems with your eyes, or your English comprehension skills. What I said is that achieving the same goals with less code is good, and if by orders of magnitude less amount of code, then that's really really good. More dependencies usually means more code in total to achieve your goals.
And about the lines of code as a useful measurement, yes they are when the differences are ORDERS OF MAGNITUDE kind of huge. A simple "Hello World" program practically has zero bug (of course it has next to nil functionality too), 600k lines of code may not differ from 500k lines of code much in terms of complexity and potential bugginess, but if THE SAME GOALS can be achieved by 600 lines of code instead of 600k lines of code, that's some big difference.
I don't think we are going to get anywhere, we are clearly at a disconnect and throwing insults isn't going to solve much. Let's just agree to meet in the middle on this.
no insults, just curious, is English your first language? I kinda understand what you are trying to say with "agree to meet in the middle" here, but that sounds really a little odd here, just saying.
Yes english is my first langauge. What i mean by meet in the middle, I'm saying we both respectfully acknowledge the other person side and agree to disagree.
Yeah I know what it means, just don't see it usually used like this.
I don't want to keep pinging you so I'll make this the last message, but I'm curious, how do you normally see the phrase used?
usually when there's no compromise it's just agree to disagree.