Clean up datasource template

[bajtos]

This is a follow-up issue for #5000 where we moved datasource config from JSON files to TS files and discovered few aspects of the datasource template that can be improved.

• Update https://github.com/strongloop/loopback4-example-shopping to follow the new style
• Update https://github.com/strongloop/loopback-next/blob/master/docs/site/Inside-Loopback-Application.md to follow the new style
• Make the static DataSource property name read-only, set it from config.name to avoid duplication.
• Rework datasources to receive the configuration via @config, so that they can be configured via app.configure(). Update the docs (especially Cloudant & Bluemix guides), make sure to preserve content for the old configuration style (think of existing projects created before the change).
• Fix datasource files in examples to use the same style as scaffolded by lb4 datasource. Most notably, change them to participate in app life-cycle and disconnect when the application has stopped. Update the docs accordingly.
• Verify that integration tests instantiating datasource classes directly are stopping them after the tests are over + update the relevant docs (e.g. testing best practices).
• Remove start/stop code in favor of stop() method provided directly by juggler, see feat: implement DataSource.stop() loopback-datasource-juggler#1835 and feat: remove hand-written datasource stop() method #5279

Acceptance criteria

For each of the items above, consider the following places to update

• The template in packages/cli/generators/datasource/templates/datasource.ts.ejs
• The template used by CLI tests - see getSourceForDataSourceClassWithConfig()
• All documentation pages in docs/site, do a text search to find all snippets showing a datasource
• All example applications in examples

---

🎆 Hacktoberfest 2020

Greetings 👋 to all Hacktoberfest 2020 participants!

Here are few tips 👀 to make your start easier, see also #6456:

• Before you start working on this issue, please leave a comment to let others know.
• This issue consists of several tasks to work on, it may feel like a too big effort to undertake. Don't worry! It's perfectly fine to pick just one item from the list and leave the rest for somebody else. In fact, we prefer to have a dedicated pull request for each part, to make it easier for us to review the changes and get the pull request landed faster. Baby steps FTW! Remember, every little helps.
• If you are new to GitHub pull requests, then you can learn about the process in Submitting a pull request to LoopBack 4.
• If this is your first contribution to LoopBack, then please take a look at our Developer guide
• Feel free to ask for help in #loopback-contributors channel, you can join our Slack workspace here.

[mrmodise]

@bajtos am interested in contributing on this. Maybe start with point 1 & 2 as a starter since am new to Lb contribution

[bajtos]

am interested in contributing on this. Maybe start with point 1 & 2 as a starter since am new to Lb contribution

@mrmodise awesome 👍🏻 Starting with the first two items is fine, I'll review your pull request the other issue you created in a moment.

[mrmodise]

am interested in contributing on this. Maybe start with point 1 & 2 as a starter since am new to Lb contribution

@mrmodise awesome 👍🏻 Starting with the first two items is fine, I'll review your pull request the other issue you created in a moment.

Thanks raised PR but having issues with grPc connection and Travis CI commit-linting

[mrmodise]

Also wanted to get your thoughts on having the config object inside the datasource.ts. What I discovered on our projects at work is that these tend to grow in size for complex projects (ours are around 400 to 500 lines). Would it not be ideal to move these ito a config folder and have them listed underneath here following the same conventions as when we were using JSON files?

[bajtos]

What I discovered on our projects at work is that these tend to grow in size for complex projects (ours are around 400 to 500 lines).

Interesting. What kind of configuration or code are you putting into your datasources? I would like to better understand your use case.

[mrmodise]

What I discovered on our projects at work is that these tend to grow in size for complex projects (ours are around 400 to 500 lines).

Interesting. What kind of configuration or code are you putting into your datasources? I would like to better understand your use case.

We don't change the default config on the datasource Classes. The only change we do is we import the config from a different file since these will be longer due to many systems we are integrating with.

so in our datasources we only change the dsConfig to point to the imported config, which will have many operations thus the longer length

[bajtos]

which will have many operations thus the longer length

IIUC, you are using loopback-connector-rest? I see how a large configuration of operations can make the datasource file difficult to maintain.

Personally, I would keep options like connector and baseURL inside the main .datasource.ts file and move only operations into a different file (or multiple files).

Maybe we can introduce some sort of a convention for loading definitions of REST operations from external files, perhaps there can be one file per operation template? I think this would be best discussed in a new GitHub issue though.

[mrmodise]

operations

Thanks. Will log an issue and move the conversation over there