[WIP] Vanilla TypeScript sample

[mauroservienti]

WIP don't merge

Vanilla TypeScript sample

PoA

• WebAPI hosts to expose real sales and shipping data
• super simple SPA to read and compose data coming from back-end directly in the browser

Description

This PR introduces a demo of a composite UI hosting the composition infrastructure directly inside the SPA built using TypeScript

[adamralph]

Would it be better to use the existing demo endpoints, and add a third solution which has only the typescript SPA project plus the necessary backend endpoints?

[mauroservienti]

there are pros and cons, moving these along with the other 2 demos (that are already mixed) might complicate a lot evolution, simply because when one solution is open we might change something that works in the open solution but breaks others. I'd prefer them to be separated, the actual 2 .NET Core demos together are already too complex IMO.

[mauroservienti]

especially now that @HEskandari is working on the polymer one, there will be a fourth one

[adamralph]

@mauroservienti would it help if we put the two current demos back into the same solution, as you originally had it? Now that I'm more familiar with the code, I think it may make more sense.

[mauroservienti]

it solves the problem but open up the nightmare of multiple startup profiles when you want to switch from demo x to demo y

[adamralph]

Would it not be a case if switching just one of the projects each time, e.g. Composition Gateway/MVC/ Typescript/Polymer? All the other start up projects would remain the same, no?

[mauroservienti]

Yes, but you still need to use that crappy multiple startup projects VS dialog to change one project in the list. Be aware, I'm not against merging it'll make back-ends evolution much simpler, but at the same time every single time we evolve a back-end all front-ends demos must be kept in sync in one go, otherwise they'll be broken.

[adamralph]

you still need to use that crappy multiple startup projects VS dialog to change one project in the list

Personally I'm fine with that. Switching one project off and another on is simple enough.

every single time we evolve a back-end all front-ends demos must be kept in sync in one go

Fair point, but I'm wondering which is the lesser of two evils. Having to rev all the front end projects synchronously, or having to maintain 4 separate sets of back end projects.

[mauroservienti]

my question is: are you familiar with polymer or typescript or WPF or whatever stack we have in the pipeline? the more front-ends stack we have the more complex updating them will become in one go. It'll also make a change dependent on many different people.

We can always try and split them again in the future.

[adamralph]

As discussed, we won't be putting any concerted effort into this just yet.

[mauroservienti]

Closing for now, I’ll re-open as I have bandwidth to work on this again.

[mauroservienti]

I’d leave the branch in place so to not lose anything.