Vue route/component(s) for Listing -> new

[robrobbins]

Referencing #5 bullet 1

• router entry
• vue component(s)
• what is the exact URL?
• other?

[thirtyaughtsix]

Firstly, components. I initialized the app via Vue CLI with SPA enabled so it's unabashedly, unapologetically SPA. I still think that's the right call. But it's far too early to have any clarity on whether the main SPA gets broken out into multiple distinct Vue applications (for the record managing communication between such apps is often a pain in the ass and I'm not familiar with the best practices in Vue-land for packaging and deploying such configurations. In React-land I've had webpack plugins handle it). (One other aside is that Vue has specific configurations for Progressive Web Apps and these configurations are intended to play nicely with its SPA configurations meaning it may not be necessary to fracture an SPA for performance reasons). For now I think we can just assume one monolithic SPA. That means the component hierarchy looks like:

- App: 
    |- lister
          |- ListingCreator: ProtocolClient 
          |- FileUploader: DatatrustClient
                        |- dropzone

(See #13, #14, #15)

So then routes...

There are hard/physical routes and soft/virtual routes. The soft routes, configured in the Vue router, can be changed at any time really - not considering SEO/cache consequences. If we assume a largely SPA design then the FE doesn't really care about hard routes per se. But given the dependency on non-origin remote resources is probably why @robrobbins cares about routes now rather than later.

I have to assume Web3 papers around/over/between any CORS issues but we'll definitely have CORS issues for the datatrust calls. The Vue CLI provides a configuration option to define a forwarding address that locally non-resolving requests to (See #12). That resolves CORS issues for the near term. When we containerize we simply reimplement the same as upstream in nginx.conf. Either way the FE, i.e. local, path should retain whatever is in the remote, i.e. proxied, path. So if the remote datatrust path is /some/path/like/this/foo/a_resource then the FE request should have the exact same path. For the most part these hard paths should have quite a bit of malleability - although that's not good cause to go and change them all the effing time.

A thought about containerization: In my last project, we containerized perhaps a bit too early (from the get go). But this was a franken-React-Spring app so it's apples and oranges. FFA has no compiled code and our "app tier" is non-existent. We probably want to containerize sooner rather than later but it's necessary to do today.

[robrobbins]

on web3 and coors: they have nothing to do with each other.

web3 only cares about communicating with some ethereum node - and we solved that already with the skynet_aws hosted node. That "provider" is the same as it was for the "end to end" test we did for the drive data.