Proposal - require dependency directly from databases instead of use `Store.use`

[jacklam718]

Proposal

require dependency directly from databases instead of use Store.use

For example:
aws = require('aws-sdk); instead of aws = Store.use('aws-sdk');
I propose this idea because I have some issues.

Background

I using AWS Lambda with serverless and serverless-webpack
I want to use eventstore with dynamodb from lambda but I got some errors. btw, I've installed aws-sdk and works on my local.

1. Implementation for db \"dynamodb\" does not exist!.

my code:

import eventstore from 'eventstore';
eventstore({ type: 'dynamodb' });

then I tried pass the DynamoDB class to eventstore, but I got another error Cannot find module 'aws-sdk' from parent
my code:

import eventstore from 'eventstore';
import DynamoDB from 'eventstore/lib/databases/dynamodb';
eventstore({ type: DynamoDB });

Some of my thoughts

About the issue 1 and 2. I think it's because it cannot find modules via require after webpack bundled.
https://github.com/adrai/node-eventstore/blob/master/index.js#L42
https://github.com/adrai/node-eventstore/blob/master/lib/databases/dynamodb.js#L2
https://github.com/adrai/node-eventstore/blob/master/lib/base.js#L172

So, that's why I propose this idea.

[jacklam718]

I could submit pull request if you agree my proposal.

[adrai]

Unfortunately this module was not designed to be used with webpack...
the strategy here is to have the database "drivers" in control of the user.
Another idea could be to have an "own" postinstall script that installs the dependency in the appropriate directory...

[jacklam718]

Ok. Thanks for the quick reply.

[jacklam718]

But why not just require('aws-sdk') from dynamodb.js directly? It can solve this issue.
And, I think serverless and serverless-webpack quite famous maybe other people will have same issue...

[adrai]

because of this: https://github.com/adrai/node-eventstore/blob/master/lib/base.js#L174
I've seen this even for prod environments

[jacklam718]

What about do something like this?

dynamodb.js

var util = require('util');
var Store = require('../base');
var _ = require('lodash');
var async = require('async');
var dbg = require('debug');
try {
  var aws = require(aws-sdk);
} catch (e) {
  // workaround when `npm link`'ed for development
  var aws = prequire(aws-sdk);
}

[jacklam718]

Because I don't want other people like me. having same issue and spend few hours to investigate 😛
Really appreciate your quick reply 😀

[adrai]

For sure this will work, but than every implementation needs to do this... that's why we have moved this to a dedicated function.

If that is a concern of several people, we can do that.

The problem is that all cqrs relevant modules are constructed that way.

I also do not understand why it's necessary to use webpack in the backend.

In the mean time I would suggest you to use your fork (if you really need webpack)

[jacklam718]

Because AWS Lambda doesn't support ES6. And, serverless-webpack is official plugin 😶

[adrai]

I know... https://twitter.com/adrirai/status/965700927670931456
but in my opinion... (really just my opinion) I would never transpile something in backend just because it's new and everyone is doing it in frontend... just wait until the real runtime is ready and available (then it's even faster and you need less code)

[jacklam718]

btw, finally I solved the issue by using babel because babel only do transpile.

[eugenio79]

I had a similar problem with eventstore and it got solved by using webpack-node-externals.

[dbartholomae]

@adrai Our main reason for using webpack is that we write our code in TypeScript. Having strongly typed code is even more useful in the backend than in the frontend. Basically we have four alternatives now:

1. Try out a different transpiler to get TypeScript working - which might not actually solve the problem.
2. Find a way to get this library to work with webpack - would only make sense if this is also in your interest
3. Use a different library for CQRS - would be a shame, haven't found another good one yet
4. Drop TypeScript and typesafety - this for us is definitely out, type safety was a giant win for our code base.

What's your opinion?

[adrai]

@dbartholomae My honest opinion is: I have a "certain" opinion about TypeScript... but this is another story...
I will personally not maintain any typescript types or files here...
but as said before... this is just my opinion...
What do you think @nanov?

[dbartholomae]

Don't worry, not talking about adding typings in here ;)
Just about making it possible to use the library with a transpiler :)