I’m having a devil of a time setting up an Ember CLI client on an ASP.NET MVC server behind a reverse proxy in an IIS shop. We had been using Ember barefoot before, but now that I’m trying to live behind the superior capabilities of the CLI build, I’m having trouble finding my way through.
The paths of our URLs are in layers. I think somebody must have worked on telephone switches in a former life. The first three levels belong to the reverse proxy and deliver to the right web app. Then the next one or more levels belong to the server-side MVC and determine what set of client content is being delivered. Typically one of these is an Ember App and the others are Web APIs, but we might have a pure Razor page or two around the edges for non-client errors, unsupported browser, etc. For the pages that load an Ember CLI client, typically the default URL of the web app, the reason the customers went there , we want the client-side routing to sit on top of that URL, the only one we want the user to remember.
Hence, the three-part path in the browser when the Ember app starts isn’t a client route but a prefix. The second part of the path is the locale, so this prefix varies. So I have to convince Ember to treat the first three layers of the path, regardless of content, as the “/” route for the client-side routing . How do I do that? Is there a pattern I can give it?
(I have one other issue with delivering the static content from the dist directory through the service. I think I know the MVC routing pattern and route order I can use to deliver that, although can I get Akamai to dish all that up if I get MVC involved with static client app content? Eh. Separate matter.)
And finally - the reason this question is here rather than on StackOverflow - Am I thinking about this all wrong?