Parent/Child database entities cannot be easily seperated

[Teomayo]

Currently the serverless.yml accepts a single client which can make organization of infrastructure more difficult. Given a setup which has a Parent DB that contains x amount of functions/indexes/collections and Child DBs which contains y collections/indexes/functions, the ability to flag which DBs to update would streamline the process and make storing infrastructure more straightforward. The current workaround is to have multiple serverless.yml files separated in different folders. This would require two different access points for updating infrastructure or the use of custom scripts to do that handling.

Due to the vast amounts of architecture possibilities with Fauna there isn't really a straightforward method to solve this problem, however an idea that may be more suitable for multiple architectures could be the use of named groups in the serverless yaml file.

For example, a configuration file might look like the following:

fauna:
  client:
    secret: ${env:FAUNA_SECRET}
    domain: ${env:FAUNA_DOMAIN, "db.fauna.com"}
    scheme: ${env:FAUNA_SCHEME, "https"}
    port: ${env:FAUNA_PORT, "443"}
  
  group:
     name: one

    collections:
      example_collection:
        name: ExCollec

  group:
     name: two

    collections:
      example_collection_2:
        name: ExCollec2

 collections:
   example_collection_3:
      name: ExCollec3

And then when invoking serveless fauna deploy the groups are skipped and an additional group flag would need to be used to deploy collections/indexes/functions within that group: serveless fauna deploy --group two

the handling of the secrets would likely need to be left to the user. So, although the use of some custom scripts would likely be needed, this would allow for having all infrastructure in one place and handled by one file.

[github-actions]

Internal ticket number is LABS-31

[rts-rob]

Thanks for the submission, @Teomayo

Agree that there's not really a straightforward way to address this. Is there a related plugin that uses named groups the way you describe that sets a precedent?

[michaelhaowu]

Definitely see a good opportunity for the tool to expand it's IaC capabilities. We're hoping to eventually rely on this solely to manage all the DBs we have, but certainly right now there is a fair bit of effort from us to script up the exact functionalities we need to manage parent and child db specific interactions.