RFC: Switch repo to Action (maintained, updated version of Meatier)

[mattkrick]

TL;DR do you want a Meatier that is updated at the cost of being slightly more opinionated?

Since I published Meatier, I got hired to basically build it into a legit marketable product. That product is open source & found here: https://github.com/ParabolInc/action/.

I don't have the time to backport all changes to Meatier, so what I'm proposing is replacing the current Meatier with Action as it currently is.

Pros:

• Up-to-date packages!
• CSS in JS!
• Popular example patterns like user presence, deploying to S3, DB migrations, react-driven emails, etc.
• You can still use it as a boilerplate-- just nuke server/graphql/models and universal/modules and you're set to make your own app!

Cons:

• Uses Auth0 (it's free to small apps) instead of a completely custom GraphQL auth solution
• ???

@devel-pa @wmertens you guys put in a LOT of hard work in your PRs to update Meatier & I feel like crap not having the time to fully test them out.

[wmertens]

I think it's a good idea, bitrot is not good and meatier actually is reasonably well known.

I am working on my own framework though so for me it doesn't matter much any more :) I took several good ideas from meatier, for which I thank you.

[mattkrick]

@wmertens nice! anything with an external message queue? I really wanna take the graphql from apollo with the simplicity of deepstream & the CRDT nature of swarm & mash it into something with amq or redis, but just don't have the business need yet....

[jordanh]

@mattkrick not yet, but SOON ;)

[KnowledgeGarden]

Just curious: Meatier is licensed MIT; what happens when you switch to the action codebase in terms of license?

[jordanh]

@KnowledgeGarden: that's a good question! There is a difference between licenses: Action is licensed under the GNU AFFERO GENERAL PUBLIC LICENSE, Version 3.0. We did this to dissuade would-be competitors from making changes to our application without returning them to the public. Open-source SaaS is somewhat virgin territory. That said, we're interested in licensing our application this way, not the framework behind it.

Our company, parabol.co, reserves the right to relicense the source base. So, if there were community momentum around extracting the application framework (as @mattkrick said, by nuking server/graphql/model and universal/modules, etc.) and, say, perhaps implementing TODO MVC or the original Metier app, we'd be supportive of licensing it under something like the MIT, Apache, or similar.

What do you think of the GPL? Too restrictive? Too difficult to isolate your own code? Or, ok?

[KnowledgeGarden]

I shall reply by email, and thanks for having this conversation. I think license issues are worthy conversations so long as religious belief mechanisms don't get in the way. That you asked strongly suggests this is an open-ideas conversation.

I wrestle with the questions you ask all the time. At one time, I planned to put my OpenSherlock (an open source Watson) under AGPL, not for reasons of making it difficult for others to use it; after all, good folks like Neo4J take care of that by putting Apache-licensed clients in front of their platform.

But, and what I am about to say in response to your question is purely a reflection of my own thinking, and not advice in terms of your thinking, where I finally came down was on the Apache 2 license, after they added the patent clause. My reasons are driven more out of great respect and admiration for what the Apache Foundation truly (my opinion) means for open source, open science, cancer moonshots, and so forth.

I view the Gnu licenses with great respect for RMS's intellect and intentions, but don't much agree with the political overtones they set. AGPL was invented to close a loophole in GPL, but, through a lens I sometimes use, that feels like greedy behavior where outright collaborative mindsets should prevail.

So, I cannot tell you what to use, though whatever it might be, injecting an Apache-licensed client between you and the outside world makes a lot of sense.

Your specific reason for choosing AGPL is already fully covered by GPL -- all the Gnu licenses, including LGPL -- cover that. AGPL only means this: with GPL, if you never "publish" by which the GPL license means "distribute" the code itself, then you are not bound to the license. That is, if I take some GPL platform and hang a bunch of private code on it, the license only applies if I give you a distribution of that, say, with my code compiled and not open source. I can put it online, let you play with it online, and that's not distribution. AGPL says: that's distribution. So, this suggests that the bets you wish to cover might already be covered by GPL, unless you actually see the issue of distribution the way AGPL does.

It's your call.

Cheers! Jack

On Mon, Jan 2, 2017 at 9:41 PM, Jordan Husney notifications@github.com wrote:

@KnowledgeGarden https://github.com/KnowledgeGarden: that's a good question! There is a difference between licenses: Action https://github.com/ParabolInc/action is licensed under the GNU AFFERO GENERAL PUBLIC LICENSE, Version 3.0. We did this to dissuade would-be competitors from making changes to our application without returning them to the public. Open-source SaaS is somewhat virgin territory. That said, we're interested in licensing our application this way, not the framework behind it.

Our company, parabol.co, reserves the right to relicense the source base. So, if there were community momentum around extracting the application framework (as @mattkrick https://github.com/mattkrick said, by nuking server/graphql/model and universal/modules, etc.) and, say, perhaps implementing TODO MVC or the original Metier app, we'd be supportive of licensing it under something like the MIT, Apache, or similar.

What do you think of the GPL? Too restrictive? Too difficult to isolate your own code? Or, ok?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mattkrick/meatier/issues/176#issuecomment-270054655, or mute the thread https://github.com/notifications/unsubscribe-auth/AAn-VpaFoONSUSFQ2gOmbdAbnhhTYjRJks5rOd9ugaJpZM4LPlFm .

[theobat]

@mattkrick, @wmertens JUst asked a bunch of things on the gitter a few weeks ago essentially my questions were:

• What is the file structure logic behind having universal/component and container in the root folder vs universal/modules/*/component and containers ? What's for what ? I feel like modules are page-like part of the app and component, containers are generic kind of things but that feels a bit unclear.
• What drove to the conclusion of dropping immutable (in action but @wmertens seemed to agree) ? is that only because https://github.com/mattkrick/cashay is not using it (and seemingly does not need it since state diffs are automated sort of) ? I feel when you need a hand written duck like when you need your own custom graphql auth module (like in meatier) it does a good job at preventing you from accidentally modifying the state and I don't see any drawback...
• Also is there any potential for a PR for query batching in cashay or is this completely out of scope for the tool ? And on the same note, is cashay really worth the trouble if not using @live a lot ? (still struggling to understand the use of @cache)

Thanks ! (learning more than coding for the past few months, still having trouble to see if cashay is required on my end)

[mattkrick]

@theobat good questions!

file structure: the idea is that reusable components are stored in universal/components. Module-specific components/containers are stored in universal/modules. containers are smart, components are dumb (If react is a MVVM then components = view, containers = viewmodel).

immutablejs is fine, but not every 3rd party reducer can be stuck inside an immutable Map. Since it's kinda pointless sticking a JS object inside of an immutable object, then might as well make the whole thing JS. i also don't like the currently accepted toJS() pattern where you convert the immutable to a js object in mapStateToProps. You could write a memoizing wrapper, but i like removing complexity, not adding it.

it'd be super if someone wanted to take on query batching for cashay! Unfortunately it's not needed for our scrappy little startup right now so I just haven't prioritized it yet.

[mattkrick]

The path forward: AGPLv3 allows me (or any member of Parabol) to fork Action and relicense it as MIT, so I'll fork it, chop out the Action-specific stuff, and then replace Meatier with Action. Then we'll have a standard boilerplate without a bunch of Action-specific modules. For folks that don't know how to do somethings (like subscriptions, server-backed DnD, etc) they could still use Action as a reference, but then they can fork Meatier to get started on their own project & be in the clear wrt licensing. Bitrot is still a risk, but at least it'll get Meatier to a place where we use CSS in JS instead of CSS modules, update redux-form, etc. Since Meatier will be a subset of Action, git merges should also be a less painful (but not pain free) way to back propagate changes that would affect both repos.