Suggestion: remove usage of ember-data

[simonihmig]

Suggesting to remove the use of ember-data here, due to these reasons:

• ember-data models seem to be only used as simple POJO-like structures, many ember-data features are not used:
  • no relationships
  • no mutation
• cut down bundle size
• show we can build ember apps without ember-data easily (a common misconception I believe?)
• show more modern build integration using pull-based imports and use of webpack plugins (see below)
• paving the way for Embroider adoption

Suggested alternative

• remove the custom broccoli-based static json build pipeline
• setup allowAppImports feature of ember-auto-import to allow (lazily) importing our own code/data, and enable integration of custom webpack plugins
• routes do dynamic imports of data: await import('../data/users')
• these data modules can just export an array of POJOs.
• where markdown processing is required, we can delegate that to off-the-shelve webpack plugins (haven't done thorough research yet, but something like this could work). So such data module could look something like:

  
  import foo from `./foo.md';
  import bar from `./bar.md';

export default const [ foo, bar ];

* the use of ember-data and generated json files fetched from ember-data adapter suggested we have a frontend/backend separation, which we didn't have really, as all was part of the same (frontend) build. The alternative suggested here does not change that, but has everything unified under an ESM/import/pull-based setup.

### Notes

This idea came up in my mind when I was looking to upgrade [ember-responsive-image](https://github.com/simonihmig/ember-responsive-image/) to the latest (beta) version, which has done the shift to pull-based imports and shifting build-integration from legacy broccoli hooks to native webpack loaders. So instead of referencing images by string-based globally unique file names, you would import them explicitly. But this doesn't play well with the setup we have here currently, as images _are_ referenced by their filenames as strings in the generated json, and that broccoli-generated json data does not allow to have imports or take part in the webpack build. The alternative suggested above would make this very easy however! This alone wouldn't justify doing this shift, but I think it makes sense on its own given the arguments laid out above, unrelated to any specific concerns of integrating the new version of the addon. "Killing two birds with one stone"

[NullVoxPopuli]

I'm in favor of this.

I think ember-data is unique enough where it al so deserves its own docs, so it can explain

• why is ember-data needed?
• what problems does ember-data solve?
• but I just have one fetch? why would ember-data help?
• reactive data-fetching? (outside routes)
  • reactive state (is loading, errors, etc)
• caching strategies
• auth
• proxies
• etc
• etc

data is too complicated of a topic (imo) to just be sprinkled here and there without deep dives.

[simonihmig]

@NullVoxPopuli are you talking here about removing/extracting ED content from the website? Because my point described with this issue was to remove ED from the internal implementation of the website!

[NullVoxPopuli]

ah I see -- I'm in favor of both. I believe ember-data also wants their own docs site, but they want all the same versioning infra the ember-source guides/docs have. (right now, they are building out a bunch of markdown documents in the repo)