4 ms·

Why is this project so popular? I’ve built mini APIs to do this in several previous jobs - either for the purpose of fuzzing, anonymizing real user data for tes

by exdsq 5y ago

Why is this project so popular? I’ve built mini APIs to do this in several previous jobs - either for the purpose of fuzzing, anonymizing real user data for test environments, or readable testing. Each time it’s taken maybe two days of effort in total starting simple and growing for internal needs. How has this been funded so much, for something that’s as simple as dictionary.getRandom()? And why does it need eight contributors, social media accounts, etc?

jffry 5y ago
Because for some people, they don't want to spend the extra time to build and maintain a solution that they are now responsible for. `npm install --save faker` and boom you have access to a huge variety of random test data, across different locales. Doesn't stretch my imagination to see the appeal.
- exdsq 5y ago
  Sure but realistically most people only use a few of fakers features right? It’s not that time consuming to make in-house. And after those few hours of work you don’t have a dependency/new security vector to consider. I guess the JS ecosystem like to import everything (isOdd).
  - jffry 5y ago
    Building something in-house comes with its own sets of pros and cons, which can be compared against the pros and cons of taking a new dependency. The balance and the "correct" decision will vary by team/project/org.
    - exdsq 5y ago
      Of course! That's good engineering. However I argue that the default is far too often to use something 'off-the-shelf' and trusting it A) works, B) is secure, C) is supported, and D) will remain so for the lifetime of your project. I wonder if those who say "2 days?! Just npm install!" answered those questions, or if they googled "nodejs fake data generator" and installed it onto their businesses main product in the next 5 minutes.
- deleted 5y ago
  [deleted]
- abraham 5y ago
  Note that for this new community version its: `npm install @faker-js/faker --save-dev`
  - exdsq 5y ago
    This just helps my point, I believe. Someone is going to google how to import fake data, find the npm repo with loads of downloads, import it, read a stackoverflow issue on how to use it, and not understand why it's broken for a while (because it's now a dead project). All so they can get a dictionary of first names and strings that look like addresses in a unit test somewhere, probably.
- DrFell 5y ago
  A lot of webdev is just pre-built stuff. When webdevs say "don't reinvent the wheel" it means "I'm too scared of doing it wrong to program it myself."
  - ZephyrBlu 5y ago
    More like "I don't want to waste time building something low impact when I could pull in a dependency and be working on something high impact".
    - exdsq 5y ago
      It's a combination of both. You're weighing up the time to build the right thing for yourself vs picking something up from the shelf. Specifically you have to factor in: 1) Is the project built correctly 2) Is it the correct project for your issue 3) Is the project maintained 4) Is the project going to be maintained for the lifetime of your project 5) Is the project secure, and how risky is including it to your project? And if these are all good then sure, it makes sense to include it in your project. And this is good engineering. But what people seem to do is go "Oh hey, I need to get a random name from a dictionary of names. Let's google that. Oooh faker!" without even thinking these questions through.
  - slenk 5y ago
    No, they value their time more than re-writing a known algorithm/pattern.
trowawee 5y ago
> I’ve built mini APIs to do this in several previous jobs [...] Each time it’s taken maybe two days of effort So...just you, in your career, have spent between 1 and 2 total weeks of developer time building the exact same functionality, and you're curious why an open source project that cuts that time down to like an hour is popular? I'm also a little suspicious of the claim that it's the exact same, because Faker has a lot of functionality under the hood, but you've more or less demonstrated why it's useful in this comment.
- bogwog 5y ago
  I think you misread "days" as "weeks
  - PeterisP 5y ago
    No, "several previous jobs" and "each time, two days of effort" does come out to a week or two.
- exdsq 5y ago
  Yes but for the sake of a few hours you now have 22 dependencies and a new security vector to consider :) And of course the reason this new version exists is because the previous version was deliberately broken. Why add significant dependencies for the sake of a few hours (maybe a day or two in the long run if you need to add functionality)?
  - trowawee 5y ago
    So, a few answers. A) most of the dependencies that Faker has are common with lots of JS projects that I work/have worked on in the last few years. Looking at that dep list[0], I'm familiar with most of them. They're mostly common packages. To some degree, I'm relying on the thousand eyes here. B) In terms of security risk, Faker runs in test suites to generate data and locally on dev machines, sometimes, to populate sample DBs. It lives and runs in managed environments and doesn't get packaged into prod anywhere. The risk profile isn't nonexistent, but it's also not a massive risk. C) I really think we're underrating the amount of work that would required to recreate this project (not uncommon here). Faker can spit out 205 different types of random data in 46 different languages/dialects. Building that is not a two day project (evidenced in the fact that people have been working on this for years now); making sure you can generate all that data correctly in all those different languages is a non-trivial task; building and maintaining it internally will take dev time and energy and will continue to require that time and energy on an ongoing basis. You're talking about this choice here and in other comments with an air of "silly JS devs, just build this easy thing!". I don't know if it's your intention, but you're coming off dismissive and ignorant. People think about these tradeoffs all the time, and sometimes decide to use packages like this. I think it might behoove you, if you find someone's decision confusing, to start from the position that they are also reasonably competent professionals and see if you can understand why a competent professional might make a different decision than the one that seems obvious to you, rather than assuming that if someone makes a different decision they're stupid and/or incompetent. [0]: https://github.com/faker-js/faker/blob/main/package.json https://github.com/faker-js/faker/blob/main/package.json
TameAntelope 5y ago
It's really nice to have a project that someone's thought through about how to build sample data a lot more than I have time to think through. Could I/anyone else build this? Of course. Could I do it so thoroughly, provide support for it, and still do my day job? Not easily, not as easily as I could install this project and use it. Also keep in mind it's not like those 8 contributors are throwing a full 40 at this project every week.
zomglings 5y ago
This is the modern JS philosophy - don't reinvent the wheel taken to an extreme e.g. left-pad (https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad) which had its own very public fiasco around the developer deleting the npm package. I don't think it's a bad philosophy, just different perhaps from yours (and mine).

by exdsq 5y ago

jffry 5y ago

Because for some people, they don't want to spend the extra time to build and maintain a solution that they are now responsible for. `npm install --save faker` and boom you have access to a huge variety of random test data, across different locales. Doesn't stretch my imagination to see the appeal.

exdsq 5y ago
Sure but realistically most people only use a few of fakers features right? It’s not that time consuming to make in-house. And after those few hours of work you don’t have a dependency/new security vector to consider. I guess the JS ecosystem like to import everything (isOdd).
- jffry 5y ago
  Building something in-house comes with its own sets of pros and cons, which can be compared against the pros and cons of taking a new dependency. The balance and the "correct" decision will vary by team/project/org.
  - exdsq 5y ago
    Of course! That's good engineering. However I argue that the default is far too often to use something 'off-the-shelf' and trusting it A) works, B) is secure, C) is supported, and D) will remain so for the lifetime of your project. I wonder if those who say "2 days?! Just npm install!" answered those questions, or if they googled "nodejs fake data generator" and installed it onto their businesses main product in the next 5 minutes.
deleted 5y ago
[deleted]
abraham 5y ago
Note that for this new community version its: `npm install @faker-js/faker --save-dev`
- exdsq 5y ago
  This just helps my point, I believe. Someone is going to google how to import fake data, find the npm repo with loads of downloads, import it, read a stackoverflow issue on how to use it, and not understand why it's broken for a while (because it's now a dead project). All so they can get a dictionary of first names and strings that look like addresses in a unit test somewhere, probably.
DrFell 5y ago
A lot of webdev is just pre-built stuff. When webdevs say "don't reinvent the wheel" it means "I'm too scared of doing it wrong to program it myself."
- ZephyrBlu 5y ago
  More like "I don't want to waste time building something low impact when I could pull in a dependency and be working on something high impact".
  - exdsq 5y ago
    It's a combination of both. You're weighing up the time to build the right thing for yourself vs picking something up from the shelf. Specifically you have to factor in: 1) Is the project built correctly 2) Is it the correct project for your issue 3) Is the project maintained 4) Is the project going to be maintained for the lifetime of your project 5) Is the project secure, and how risky is including it to your project? And if these are all good then sure, it makes sense to include it in your project. And this is good engineering. But what people seem to do is go "Oh hey, I need to get a random name from a dictionary of names. Let's google that. Oooh faker!" without even thinking these questions through.
- slenk 5y ago
  No, they value their time more than re-writing a known algorithm/pattern.

trowawee 5y ago

> I’ve built mini APIs to do this in several previous jobs [...] Each time it’s taken maybe two days of effort So...just you, in your career, have spent between 1 and 2 total weeks of developer time building the exact same functionality, and you're curious why an open source project that cuts that time down to like an hour is popular? I'm also a little suspicious of the claim that it's the exact same, because Faker has a lot of functionality under the hood, but you've more or less demonstrated why it's useful in this comment.

bogwog 5y ago
I think you misread "days" as "weeks
- PeterisP 5y ago
  No, "several previous jobs" and "each time, two days of effort" does come out to a week or two.
exdsq 5y ago
Yes but for the sake of a few hours you now have 22 dependencies and a new security vector to consider :) And of course the reason this new version exists is because the previous version was deliberately broken. Why add significant dependencies for the sake of a few hours (maybe a day or two in the long run if you need to add functionality)?
- trowawee 5y ago
  So, a few answers. A) most of the dependencies that Faker has are common with lots of JS projects that I work/have worked on in the last few years. Looking at that dep list[0], I'm familiar with most of them. They're mostly common packages. To some degree, I'm relying on the thousand eyes here. B) In terms of security risk, Faker runs in test suites to generate data and locally on dev machines, sometimes, to populate sample DBs. It lives and runs in managed environments and doesn't get packaged into prod anywhere. The risk profile isn't nonexistent, but it's also not a massive risk. C) I really think we're underrating the amount of work that would required to recreate this project (not uncommon here). Faker can spit out 205 different types of random data in 46 different languages/dialects. Building that is not a two day project (evidenced in the fact that people have been working on this for years now); making sure you can generate all that data correctly in all those different languages is a non-trivial task; building and maintaining it internally will take dev time and energy and will continue to require that time and energy on an ongoing basis. You're talking about this choice here and in other comments with an air of "silly JS devs, just build this easy thing!". I don't know if it's your intention, but you're coming off dismissive and ignorant. People think about these tradeoffs all the time, and sometimes decide to use packages like this. I think it might behoove you, if you find someone's decision confusing, to start from the position that they are also reasonably competent professionals and see if you can understand why a competent professional might make a different decision than the one that seems obvious to you, rather than assuming that if someone makes a different decision they're stupid and/or incompetent. [0]: https://github.com/faker-js/faker/blob/main/package.json https://github.com/faker-js/faker/blob/main/package.json

TameAntelope 5y ago

It's really nice to have a project that someone's thought through about how to build sample data a lot more than I have time to think through. Could I/anyone else build this? Of course. Could I do it so thoroughly, provide support for it, and still do my day job? Not easily, not as easily as I could install this project and use it. Also keep in mind it's not like those 8 contributors are throwing a full 40 at this project every week.

zomglings 5y ago

This is the modern JS philosophy - don't reinvent the wheel taken to an extreme e.g. left-pad (https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad) which had its own very public fiasco around the developer deleting the npm package. I don't think it's a bad philosophy, just different perhaps from yours (and mine).