3box / 3box-services-box Goto Github PK

At the very least have containers write to log file on my system so that i can tail the file and write filters over it. Second iterations could use better logging libraries.

Add 3Box dapp as service and allow it spin up with configs of all other services

And make sure to configure in 3box-js

Export a config file of all the hosts:ports of each service that become available when you run them. Then in be imported into other places that want to spin up services and run against them.

UNLICENSED_DEPENDENCY - coinstring (2.3.0)

It's a transitive dependency of ethereumjs-wallet used in truffle-privatekey-provider.
The latest version of ethereumjs-wallet doesn't use coinstring anymore so we could try to upgrade truffle-privatekey-provider to use it, or see if we can remove or replace truffle-privatekey-provider.

Once we are trying the the iframe again lets add it here. This setup makes it easy to rapidly iterate on iframe/lib and try in different browsers.

Diverged since building, difficult to run current branch. Recent work work last sprint has made it easier to wire up some services in services box, should not be far from having an easy to user master branch (vs just locally working repo right now)

4 services should share the same file store

@msterle commented on Tue Dec 17 2019

@msterle commented on Tue Dec 17 2019

@msterle commented on Tue Dec 17 2019

UNLICENSED_DEPENDENCY - detect-dom-ready (1.0.2)

Imported through ipfs > libp2p.
It seems that the latest version of libp2p is no longer using it so I expect updating the IPFS dependency would solve the issue.

Right now some of the services referenced are referenced by specific commits that implement compatibility or compatibility hacks. We need those commits to get into their respective develop branches so that we use any commit/branch in a project/service going forward.

May be useful to have each project have their own dockerfile so they that they are available in each project individually. Just added here to quickly start first iteration.

• CORS issue
• When incorrectly stopped (often happens with Docker), IPFS cannot restart

Adding a single key increases load time, what is happening 2 → 4 seconds

Time to load/open increases fairly rapidly which number of keys/entries, does not take much to add a second. Have a feeling its more than linear.

Worst is cached data shows similar increases, even though its locally available, whats happen here? I would assume this should be fast? Is sig verification slow, maybe could cache that verification for each client?

When rapidly adding keys, all show up at first when fetching all keys, but then page reload (even with cache) only returns some of them after about 1/10. Same is found from pinning server after, sometimes even less. Even though adds are reported successful. Will have to find tighter bounds on time here? what if adds spaced by second?

There is some interdependence between stores/boxes. Open 2 for the first time (load from server) slows the other down. Both 8 secs, after one 2 secs the other 4/5 when loaded the second time from cache

Also interdependence with onsync done, open two different boxes, only one will call on sync done.

Boxes with more keys seem to open less reliably, sometimes not opening at all. While another box with fewer keys opens at same time. Often happens first reload after adds, and then works on subsequent ones again. This is is not reliably true.

Eventually go one to not open at all again, by adding many keys over and over, and stopping mid process.

MBs get added quite to slow to indexed db? some processing not data has to be slow

MBs increase when adding keys, but even though many keys are lost as mentioned above, the storage still increases on next open.

^ until you delete and reload, then more keys and entries are lost, also don't understand why the underlying log is not longer than the number of keys if am constantly changing keys. Once stuff was loft they were often equal in length.

When using cache, openbox time increase quite a bit keys/data. 500+ keys(or entries) and 30mb of data increase load time to about 15/20 seconds. Concerning this using local cache.

Exact values not simulate here yet, but Kenzo had close to 500 entries and 100mb and was seeing 30 second or more load times.

So this would align roughly with what @michaelsena and @oznekenzo have reported.

Also don't know where all the data overhead is coming from (have to look at log entry format), since added KBs worth of string chars and end up with 30mb in indexeddb