[core] Investigate atmosphere dependencies (discussion encouraged)

[pozylon]

Dependencies that need investigation:

• aldeed's schema packages: collection2, schema-index & simpl-schema. These are still maintained but only on a irregular base. We should find out the cost and potential of getting rid of these packages. -> Currently the schemas are almost only used as input cleaning in update/insert operations to the db and migrating the code together with index creation would only take 1 or 2 days of work for the whole unchained-engine. We stick to the current usage to keep that window open (refactoring out the dependencies) but don't encourage a more intense usage of these packages

• the dburles:collection-helpers package is very small and does not use any meteor specifics so it might make sense to just copy over the code and mention the licensor in the readme of unchained.
  -> PoC in form of a partial refactoring of the package core-countries in a functional style without collection-helpers

• the dburles:factory package introduces further dependencies, espoecially one to minimongo for the LocalCollection. It might make sense to replace the package completely with an npm package

Currently considered non-replaceable:

• percolate:migrations (used by core-payment, core-delivery, core-logger, core-users)
• ostrio:files (abstracted by core-files)

[macrozone]

simpl-schema is well maintained in my opinion and still widely used.

dburles:collection-helpers on the other hand:

i would get rid of it, but not because it is not maintained, but because it enforces bad practices:

• business logic is currently inside helpers, but should be framework agnostic and pure
• it adds a unessesary layer to the data and it mixes three responsibilities in its current state:
  • computation of properties that are relevant for the client --> should be done in resolvers
  • computation of properties that are relevant for the businesslogic inside the server --> should be done in pure functions (these can be shared with resolvers easily)
  • doing operations on data --> should also be done in functions

personally, i think functional style is better for this kind of business logic than the oop-style that is currently in place.

[pozylon]

Thanks for sharing your opinion on that, I share your view on collection-helpers, it's better to keep things pure when it comes to business logic. I also would like to try out a more functional approach and we could try to just refactor a very small core module that has all of the above (client computations, business logic computations, operations on data) like core-countries to see how it feels like in contrast.

[pozylon]

Closing in favor of #115