support multiple s-models.json|yaml files within anywhere of the project's space

[nickchisiu]

the plugin should be modified to support s-models.json|yml for different functions as different files like s-function.json|yml instead of supporting only a single s-models.json|yml file stored in the main project root directory ( that file gets huge when you add more models for API endpoints )

[HyperBrain]

A feasible solution is to extend the JSON refs that currently only allow referencing to local models, so that files or even remote references can be specified.
This is an easy change as the file and remote references just have been disabled and have to be turned on in the options of the json-ref module.

Example

  ...
  "properties":
    "mySubModel1":
      "$ref": "./models/mysubmodel.yaml"
    "mySubModel2":
      "$ref": "https://mymodelrepository.company.com/mysubmodel2.yaml"
 ...

[nickchisiu]

yes, that's a nice solution for referring models outside of the current file . But for example if you want to maintain 2 or more different s-models.json|yaml files without even having the refs usage there , it would be something like :

functions
└── v1
    └── auth
        └── register
            └── POST
                ├── event.json
                ├── handler.js
                ├── s-function.json
                └── s-models.json
        └── login
            └── POST
                ├── event.json
                ├── handler.js
                ├── s-function.json
                └── s-models.json

I implemented something similar with this with Swagger models for a customer, so the final solution was on having one single big models object builded from multiple models files and this way you can reference anything from a file to another because the models are merged in that single object and they have direct access to each other . I'll try to do a quick implementation for that to prove my intentions.

[HyperBrain]

Ok, agree. IMHO the new version should have both variants included.
What you mentioned follows the same semantic like the s-template.json files. So that the models are merged on deploy. The only pitfall would be that you have the same model defined in two adjacent levels. The deploy must therefore load all models even on a single function deploy, as the model definitions are global per AWS API and bail out with an error if such inconsistencies are encountered as subsequent deploys would break the existing already uploaded models in that case.

[nickchisiu]

yep, true. It could be added a sanity check feature there and throw an error if there are duplicate models names on different files, so this way models are not getting unconsciously overwritten. For the issue with updating only the modified models I would suggest some more generic implementation like a sync/caching feature , I'm trying to think best "generic" I can with the new upcoming support for multiple microservices providers like Azure, Google Cloud , etc . and having compatible features with the most of those.