appConfig - are the file paths really necessary?

[oliversturm]

The structure of the config blocks for aggregates, read models and other parts requires me to pass the relative path for each source code file:

  aggregates: [
    {
      name: 'aggregate-name',
      commands: 'common/aggregates/aggregate-name.commands.js',
      projection: 'common/aggregates/aggregate-name.projection.js',
    },
  ],

This seems unusual, and extra work for maintenance. Of course there are many ways of building up this structure. I think there are two aspects that are strange for reSolve:

1. The fact that the file names are given as they are
2. The forced separation of commands and projections - a bit more opinionated than necessary.

To provide an example of a contrasting implementation, here is some code from a demo that uses my own CQRS/ES framework. This is an aggregate implementation - never mind the details, but you can see that all aspects are handled in the same place. Of course I would still be free to separate command and projection related code - this way it's left to the dev which way they prefer.

// aggregates/customer.js
module.exports = {
  initial: () => ({}),

  commands: {
    CREATE: (aggregate, payload) => {
      doesntExist(aggregate);
      has(payload, 'name');
      return { type: 'CUSTOMER_CREATED', payload };
    },

    UPDATE: (aggregate, payload) => {
      exists(aggregate);
      has(payload, 'name');
      return { type: 'CUSTOMER_UPDATED', payload };
    }
  },

  projections: {
    CUSTOMER_CREATED: (aggregate, { timestamp }) => ({
      ...aggregate,
      creationTimestamp: timestamp
    })
  }
};

And then I have this to accumulate all aggregates:

// aggregates/index.js
module.exports = {
  customer: require('./customer'),
  order: require('./order')
};

I think this is a pretty compact and standard structure without enforced maintenance overhead. Couldn't the reSolve config work this way?

[IhostVlad]

Hi, @oliversturm ! As I understand it, this issue actually raises two questions: how to import resources into a configuration file and how resources are divided into their component parts.

The first part is discussed in detail in the earlier issue #1361 . In a nutshell, it's impossible to perform direct resources import in app.config, because the reSolve framework performs massive codegeneration, and use customer application files to generate JS-code from pieces. Therefore reSolve framework claims path to files and not materialized objects from these files, because it will read source code of those files, combine it with resolve-runtime pieces, generate on-the-fly JS bundle and only then execute it.

The second part of issue is subject to discuss. Some parts of configuration file can de reduced to composite import, like you suppose above. For instance, aggregates and read-models can be joined in united file, but view-models must be placed in separate files. To preserve a universal style, it was decided to define all configuration sections as a set of constituent resources. There will probably be many questions why an aggregate can be imported as a single file, and the view model must be included as several compound files.

[oliversturm]

The second part of issue is subject to discuss. Some parts of configuration file can de reduced to composite import, like you suppose above. For instance, aggregates and read-models can be joined in united file, but view-models must be placed in separate files. To preserve a universal style, it was decided to define all configuration sections as a set of constituent resources. There will probably be many questions why an aggregate can be imported as a single file, and the view model must be included as several compound files.

Can you elaborate about the view model requirements here? A view model really only needs one file anyway - I believe the (de)serialize_state files are optional, right? In any case, why couldn't I have something like this in view-models/test.js:

export default {
  Init: () => [],

  Serialize: state => JSON.stringify(state || []),
  Deserialize: state => JSON.parse(state),

  [EVENT1]: ...

  ...

Further, are you saying that it is possible right now to combine commands and projections for an aggregate in one file? And projections and resolvers for a read model as well? If so, can you give an example?

[IhostVlad]

Main difference between read-models, aggregates, api-handlers, etc in one hand, and view-models in another hand is isomorphism. View-models are used mutually on client and server side, so isomorphic code should be imported different way than server-only code.

View-model is consists of multiple parts, and some of them are server-only for technical and security resons https://github.com/reimagined/resolve/blob/master/packages/core/resolve-scripts/configs/schema.resolve.config.json#L118-L150. For instance, view-model serializer can use Bcrypt/JWT npm packages, which are written in C++ and therefore cannot be imported in client side. Since ECMAScript language has no "unimport" semantics, where is no way no make composite file describing one view-model, because it will directly import all dependent parts recursively, and bundling will fail on server-only libraries.

Consider following simplified one-line view-model serializer import jwt from 'jwt-c++-impementation'; const serialize = (input, state) => { jwt.verify(input); return state; }; export default serialize. With your one-file example, it should be necessary to import hypothetic jwt-c++-impementation library in view-model description file. But there is no way to deliver such library onto client, and webpack bundling will fail when jwt-c++-implementation.node binary file had been reached and tried to pack into bundle. So we run into contradiction that view-model can be described in only one compound ESM-file

If example above with hypothetic jwt-c++-impementation library looks too synthetic, then it should be remembered that most of the libraries for working with encryption are exclusively server-side and are written in C ++

[oliversturm]

Okay, these are very good points - thanks for explaining. I understand that for this reason we will need to keep the split between view model files - but I would still add that these are "special' scenarios and many devs will probably not encounter them. Or perhaps I'm not understanding why this would be a common thing...

Meanwhile, I still don't think that we couldn't support a one-file scenario for aggregates and read models, if that's possible. I don't think this will result in great confusion, even more so since the core of the view model setup is also a one-file thing.

[IhostVlad]

Yes, I think you are right, and we can provide support one-file implementation for domain configuration entities, including view-models, and leave current multiple-file configuration as advanced mode for including server-only libraries in view-model parts, like encryption and serialization.

The only serious drawback in this scheme is that if the developer uses the single-file configuration for the view model, and then includes the server library there and forgets to change the configuration to the multi-file one, then the application building will fall with an unobvious error that we cannot intercept at this moment (although maybe this one https://webpack.js.org/loaders/node-loader/ can help and it is subject to research)

[oliversturm]

forgets to change the configuration to the multi-file one

That is certainly unfortunate. But the goal of the discussion in this thread is, from my point of view, to simplify the setup requirements for first-time users and 80% cases - if a dev starts doing something advanced with custom serialization of view models, they are probably outside the scope of this simplification. Of course it would be great if we could show a really useful message if they get it wrong.

one-file implementation ... including view-models,

I believe this is already possible - at least I had it set up like that in a test, and it was my impression that the standard template code (i.e. JSON.parse and JSON.stringify with a {} default value) was used automatically when I commented the two lines from the app config file.