Is your feature request related to a problem? Please describe.

Reading through the reSolve documentation, I'm specifically curious about whether clustering is natively supported. Specifically, the ability for multiple reSolve servers to be run in a cluster, where a given aggregate state is accessible to every server across the cluster, and where events can be emitted and processed by any member of the cluster.

Looking through the Application Configuration documentation, the only potentially relevant information I've found is in the eventBroker section, where you can configure publisher and consumer settings. If I want to spin up multiple reSolve servers, should I set both of these configuration options on every server?

I'd also like to know if configuring the eventBroker will also allow multiple reSolve servers to cluster in the way I've mentioned?

An example use-case for this is deploying a reSolve application into a kubernetes cluster. The application will serve an API which will dispatch commands to aggregates. You will likely want multiple instances (pods) of the server running, for availability's sake, but these instances should be aware of each-other. Otherwise, you have no way to guarantee a given aggregate is unique across the cluster of servers, you risk aggregate state getting out-of-sync between servers, etc.

Am I misunderstanding the design principles of the reSolve framework? Any clarity is appreciated here. Thanks for your input.

I think it would be useful if there was a built-in mechanism to detect whether an aggregate exists (in a command handler function) - reSolve knows this, since it has just attempted to retrieve the aggregate before the function is called. Unfortunately, the information is not passed on to the command handler and I am left to my own devices to figure it out. Since many aggregates require this logic to avoid duplicates, there is room for improvement here.

Currently, the only "good" option is to handle a special aggregate field which denotes specifically whether the aggregate exists or not. (Note - I'm aware of several other approaches that are worse than this - please let me know in case you need me to elaborate.)

So I'd have this in thing.commands.js:

createThing: (aggregate, { payload: { ... } }) => {
  if (aggregate.exists) throw new Error('Thing exists');
  ...
}

And then this in thing.projection.js:

[THING_CREATED]: (aggregate) => ({
    ...aggregate,
    exists: true,
}),

Obviously this approach works - but I don't think it should be necessary. It's boilerplate, required for almost any aggregate, and all just to detect a piece of information that is already known to reSolve!

I suggest we use one of these two approaches:

1. Pass a flag to the command function that indicates whether the aggregate is new (i.e. equal to its initial state)
2. Pass the aggregate version to the command function - this mysteriously turns up in the event structure after the command function completes. I have to admit I don't exactly understand how this version is counted, or why it would be included in the event, but I suspect that the version exists already before the command function is called even for a new aggregate and could therefore be used as an indicator.

Hi,

Thanks for sharing ResolveJS.

However, it's unclear from web site and GitHub repository what is the actual current status of the project, e.g. limitations, and future plans.

It would be great to have a page with description of current limitations and future plans, possibly with an estimated timeline, for ResolveJS.

I have ascertained some limitations by reading through issues, documentation, and StackOverflow questions but this is not optimal or transparent.

This would give me more confidence in committing a project to use ResolveJS.

Thanks, Ashley.

PS Apologies if I missed these somewhere...

At the moment we generate aggregate id and send it from a client on the create command. See Shopping List example: https://github.com/reimagined/resolve/blob/master/examples/shopping-list/client/components/ShoppingListCreator.js#L24

I discussed this with developers: pros The user creates id and it could be a meaningful value for navigation or something else. Theoretically, it is just a string and should not break anything.

cons In practice, we can send a huge string as id and broke app navigation. We have no place where to put validation for aggregate id on the server side.(update we can validate it in the command handler. Maybe need some docs on how to do.)

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?

I am hoping to figure out a way to interface with my reSolve service from a local queue worker, rather than having events posted to an API endpoint.

For example, if I wanted to have a worker consuming messages from an SQS queue - Ideally I would not need to then make an HTTP requests to get that event ingested. I would much rather simply be able to issue commands to aggregates from the worker. I originally thought a custom module may be a possible route - but the documentation in that area is pretty sparse.

Would love some guidance on an alternative to posting commands to an HTTP endpoint, and instead issuing them directly from a worker.

Even exposing the underlying express server in some way, ideally with access to the bootstrapped resolve instance. Right now it seems the express server is a black box.

1. Lerna does not perform correct bootstrapping for dependent modules, so when launching examples from it's appropriate directories, node_modules will not installed, so webpack/babel plugins can't be found
2. Socket.io server part library perform including dependent library in run-time, which is incompatible with bundling mechanism. Should be researched, how to fix it in general case, and socket.io, in particular.

Is your feature request related to a problem? Please describe. Not necessarily.

Describe the solution you'd like Like ApiHandlers, but for AMQP queues/messages.

Describe alternatives you've considered I'm currently resolving (hacking) this by starting an AMQP consumer that does a local HTTP request to an API handler (for every message on a queue) that can map the message itself to a command. I would like to access the resolve context when consuming AMQP messages.

Additional context Adding handlers for similar wire-level protocols (or those covering this and more like Kafka) might be interesting too.

Is your feature request related to a problem? Please describe. Deno and Edge functions are becoming more and more popular with services such as Supabase functions now using them.

Im wonding if resolve would ever be able to support deno?

Describe the solution you'd like A build of resolve that supports deno

'lambda@edge timeout' error occurs when polling data continuously and requests stop for some time

STR:

1. Open Dashboard Projects page with several not empty projects ( ask for an invitation to login on https://ddev.testcafe.io ). it makes requests for getLastBuilds resolver
2. Wait for a while (an hour or more, tab goes into inactive mode ) .
3. After awakening the lambda edge timeout error should appear.

Screenshots

UPD: endpoint is endpoint api/query/Builds/getLastBuilds?projectIds=

Describe the bug Read-model projection Init handler eliminates errors if one occurs.

To Reproduce Create Init handler with erroneous behaviour

Init: async (store) => {
  await store.defineTable("abc", { indexes: {"abc": "string" }, fields: [] })
  await store.defineTable("abc", { indexes: {"abc": "string" }, fields: [] })
}

Read-model with such Init handler failed to build, but error is hidden

Expected behaviour Read-model should crash with error message something like "Duplicate table name"

Desktop (please complete the following information):

• ReSolve Version: 0.33.15