decide what infrastructure to use for the paywall app

[cellog]

The split of the creator side of Unlock (unlock-app) from the consumer side (paywall) provides a chance to re-evaluate the basic structure of the app.

Currently, unlock-app uses next.js. We should consider these possible frameworks for the paywall app:

1. continue with next.js
2. create-react-app
3. other alternatives outside the typical fold, like gatsbyjs

The first question is whether the paywall app needs to have a server at all? The paywall primarily needs to access the chain using a client-side implementation, and to access locksmith over the wire, but does not create any new content.

Another consideration is the complexity of the minified paywall script versus the iframed paywall from a development perspective (#1382). Is there a framework that would make this easier?

Based on these 2 considerations, I am leaning towards a client-side only framework. The most straightforward of these is create-react-app, but gatsby also would be great.

The advantage of gatsby is that if we rebuild the paywall.min.js, and refresh the page, it will load the new version.

The advantage of create-react-app is we get webpack's reload-on-change (not the same as hot module reload). I'm not positive, but this may also allow us to get paywall.min.js changes with a page refresh.

The advantage of next.js is that we may have less changes to make to tooling (although create-react-app will be very simple, and kills that advantage), and familiarity with the design works for developer flow.

Thoughts @julien51 ? @cnasc ?

[cnasc]

Gatsby is definitely interesting, and it does convey some advantages in terms of page weight and speed since it's static.

[cellog]

It's worth noting that create-react-app ultimately would also be static (yarn build) on deployment, just dynamic while developing.

[cnasc]

Oh cool, I didn't know it could do that. create-react-app might be the way to go then for ease of development.

[julien51]

One thing to consider about create-react-app is that it packages everything until you eject... and then you're kind of left alone dealing with the mess. It's not so much whether we will eject or not, because I think pretty much every cra project ends up being limited by it. So, at least with my current understanding of things, I would not want to use CRA.

I am a big fan of consistency and given that we're a team of 5, I would be in favor of limiting the number of different things/frameworks we use. That is, for me the biggest reason why I'd recommend nextjs.

The advantage of gatsby is that if we rebuild the paywall.min.js, and refresh the page, it will load the new version.

Any idea how gatsby does this and if it would be possible to do the same with next?

[cnasc]

Not to muddy the water even further, but here's some food for thought: https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d

Paypal actually does something fairly similar to what we do with the paywall iframe. Their zoid library may make our job easier, although it may also be too much rework from what we already have.

[cnasc]

I think we're approaching a point where we have to make a decision about this and the related issues, #1447 and #1449, or we'll risk not getting it done for the next release

[cellog]

I'd like to set up a dual build of next and create-react-app. We can code as usual running next.js and when we are ready, compare the performance and dev experience of the two options and see if it makes a difference

[cellog]

For our first go, I'd like to copy en masse existing code over, so no refactors of anything, just plop it down and make it work as-is. We won't need to make final decisions about what to move towards until the split has happened and travis is set up to build, and netlify is adjusted for the change.

Once that stabilizes, then we can start to strip away unneeded things, and see what we have left, and then make final decisions about the css and state questions

[cnasc]

Works for me. So the first step on this would splitting it out into its own repo and getting it to build properly as is.

[cnasc]

New empty repo created here

[cellog]

oh, we are going to do it in the paywall directory inside the monorepo. You can leave the repo for now, perhaps we'll use it in the future

[cnasc]

Oh, I see. OK cool

[cellog]

The plot thickens! Next 8.0 is out, and has a serverless mode that we could use in the paywall. Advantage over cra is you can have multiple entry points, something cra wants but does not have yet. With the flexibility of webpack configuration overrides, next is a clear winner here. Thoughts? Oh and I think we can fix the problem of not got reloading when paywall.min.js is changed by adding it to the files that nodemon watches, which is sitting right there in package.json and was there the whole damn time :)

[cnasc]

Very yes imo.

[cellog]

decided on next 8