faker icon indicating copy to clipboard operation
faker copied to clipboard

Provide some cloud functions/modules

Open Shinigami92 opened this issue 3 years ago • 7 comments

Clear and concise description of the problem

Stuff like faker.aws.region()

Suggested solution

Draft out what is needed

Alternative

No response

Additional context

No response

Shinigami92 avatar May 14 '22 17:05 Shinigami92

Can u explain better? How this should work...

Minozzzi avatar May 17 '22 22:05 Minozzzi

Can u explain better? How this should work...

Just like faker.aws.region() // 'eu-west-1' See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions for more regions

Shinigami92 avatar May 18 '22 18:05 Shinigami92

Hey guys, I would like to try to contribute with this feature. Could you assign to me?

Minozzzi avatar Aug 17 '22 22:08 Minozzzi

Hey guys, I would like to try to contribute with this feature. Could you assign to me?

Not too sure if this feature request is accepted yet, it's been here for a while. @Shinigami92?

ejcheng avatar Aug 18 '22 01:08 ejcheng

The more important thing here is currently to collect what is needed and how we should structure it So you might not instantly open a PR for that but provide some I don't know collection of draft data and such :)

Shinigami92 avatar Aug 18 '22 04:08 Shinigami92

Today we decided in our team that we wont like to start with an implementation of this issue until we

  1. fully draft out what we want here (that's now your part @Minozzzi :slightly_smiling_face:)
  2. fully support a much better tree-shaking that also strips out locales and module functions this could take like half a year :warning:

Please write a draft that detail how you would design the cloud module(s) in this issue, please do not write a PR yet e.g. faker.cloud.aws.region() vs faker.aws.region() vs faker.cloud.region(provider: 'aws')

Shinigami92 avatar Aug 18 '22 17:08 Shinigami92

Today we decided in our team that we wont like to start with an implementation of this issue until we

  1. fully draft out what we want here (that's now your part @Minozzzi slightly_smiling_face)
  2. fully support a much better tree-shaking that also strips out locales and module functions this could take like half a year warning

Please write a draft that detail how you would design the cloud module(s) in this issue, please do not write a PR yet e.g. faker.cloud.aws.region() vs faker.aws.region() vs faker.cloud.region(provider: 'aws')

For the first point, I imagine we could use locals to do this, with faker.cloud.region(provider: 'aws'). I saw that regions can also be the same for different providers, for that we could use a base locale and create specific locales when necessary.

For the second point, I can't speak very well about it, I'm not a very experienced developer yet, so I wouldn't know how to do it

Minozzzi avatar Aug 28 '22 23:08 Minozzzi

Giving that different cloud providers could have different region names and avaliabilities, it would i think it woul be nicer if the module cloud got separated for different providers, so i should say that the formar faker.cloud.aws.region() is more Open Closed than faker.cloud.region(provider= 'aws'), for example we could define more cloud resources with the first choice like For AWS:

  • faker.cloud.aws.region() -> us-east-1
  • faker.cloud.aws.avaliabilityZone() -> us-east-1a

If later is needed to define more resources for each cloud provider we could nest the resources in each provider module like

faker.cloud.aws.service() -> lambda

If is needed to add another provider to the module:

  • faker.cloud.{provider}.{providerResource}() -> fakeData

To go deeper in each cloud resource own logic it could be also implemented

  • faker.cloud.{provider}.{providerResource}.{resourceDetail}() -> fake data

Note: The information needed for AWS regions and Availability Zones can be found using the aws CLI

  • regions: https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-regions.html image
  • availability zones: https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html image

domingo2000 avatar Oct 21 '22 20:10 domingo2000

The only issue about that is that we want to get rid of sub-modules :thinking: We already want to redesign the image-providers which is a bit similar to what you proposing.

Shinigami92 avatar Oct 21 '22 20:10 Shinigami92

True, I belive that some of the problems of the image-provider could appear here, because some cloud services change often. Some cloud Iaac solutions still separate by cloud providers, see Terraform Namespaces, it has one namespace for each big cloud provider, because the buisness logic of each is very different. There might be some organization in the cloud module like the one that they have 😄

domingo2000 avatar Oct 21 '22 20:10 domingo2000

The only issue about that is that we want to get rid of sub-modules 🤔 We already want to redesign the image-providers which is a bit similar to what you proposing.

I dont think we should get rid of the sub modules per se. The image provider is just inconsistent on how its implemented.

If were are going for submodules, then we have to adjust the docs generation to support it. I think we shouldnt go for sub sub modules though.

ST-DDT avatar Oct 22 '22 08:10 ST-DDT

See also:

  • https://github.com/faker-js/faker/issues/1475

ST-DDT avatar Oct 22 '22 08:10 ST-DDT

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

  • If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
  • If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

  • the number of votes (:+1:) and comments
  • the relevance for the ecosystem
  • availability of alternatives and workarounds
  • and the complexity of the requested feature

We do this because:

  • There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
  • Every feature we add to faker has "costs" associated to it:
    • initial costs: design, implementation, reviews, documentation
    • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

View more issues which are waiting for user interest

github-actions[bot] avatar May 05 '23 07:05 github-actions[bot]