Wednesday, 18 March, 2015 UTC
Summary
Ember is great, ASP.NET isnt so bad. I've been using them together for about a year or so now and I'm pretty happy with the stack, honestly.
However I haven't been using ember-cli all this time, which is something both the core team and the community seem to be pushing, and for good reason. It's pretty cool, you can run a few simple commands and boom - ember project set up and ready to go. It feels a lot like working with the best bits of ruby-on-rails.
Visual Studio is still Visual Studio though, it's coming on pretty nicely but it's still not exactly the most pleasant IDE when it comes to using tools like this.
So i've fought with it, looked online, read through the ember-cli docs and I think I've come up with a pretty workable solution.
The Idea
The idea is that you want to separate your API code from your front-end application, which is something I don't see a lot in the .NET space. This way you can essentially treat your API Code as if it were any other third party API, and we can do all of this with surpringly little configuration.
Setting up the Server/API
First, create a Web API project in your solution, the same way you normally would. I like to go for the Empty API project and write all of the configuration myself.
Next, change the port that the site is hosted on to something a little more friendly, you can do this in the solutions' properties. I also like to append
/api onto it too, because that's how I set it up in deployment.In the
WebAPiConfig.cs file we just need to add the following code:var jsonFormatter = config.Formatters.OfType<JsonMediaTypeFormatter>().First();
jsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();
This tells Web API to return the JSON formatted in camelCase, the way ember expects it (and it's also my preference when working in JavaScript)
Next add your routes and controllers the way you normally would (bearing in mind the /api/ is now there by default, you may want to change your endpoints accordingly).
Run this project locally, or publish it somewhere if needed and then we're ready to set up the client application.
Setting up the Client
For the client I just create an empty Web Project, you can also set the port to the same as the one you used for the API, but it's not required.
That's all the work we'll be doing in Visual Studio for now, on to ember-cli. Most of this work will be done in command prompt, or powershell, or whatever command line tool you want to use. (I use powershell)
If you don't have ember-cli you need to install it first. If you don't know what ember-cli is or how it works I recommend you take a look at it.
Then navigate to the folder where your Empty Web Project is and create a new ember application right there.
npm install ember-cli
cd #Path to your Empty Web Project
ember init
We call ember init here, instead of ember new, because the folder already exists! ember-cli will go off and generate the skeleton of our application.
Usually at this point you can just type
ember server and everything will be built and hosted locally for us. Unfortunately this isnt the case for us. It may appear to work, but as soon as you start making XHR requests to your API they'll go to the wrong place.To talk to our API we need to tell ember-cli where to send the requests. You do this by setting the --proxy flag.
The documentation for ember-cli tells us the following:
Use --proxy flag to proxy all ajax requests to the given address. For example ember server --proxy http://127.0.0.1:8080 will proxy all your apps XHR to your server running at port 8080.
This means, in our case, to start up our ember server we want to type
ember server --proxy http://localhost:9090/api.Then in the browser navigate to
http://localhost:4200 where our ember application is running. I prefer to use the ember server because we still get all of that live-reloading goodness.Horray! Everything should work now, any ajax request we make will be also proxied to the right place.
For example this ember code:
import Ember from 'ember';
import ajax from 'ic-ajax';
export default Ember.Route.extend({
model: function () {
return ajax('/people');
}
});
will head off to
http://localhost:9090/api/people to get the model for the route.All of my calls are returning a 404!
In my experience the main thing that can go wrong is that you're not running the server for your api. Head back over the visual studio and run the project with ctrl+f5. You don't need to keep the browser open!
Making life a little easier
Having to start the ember server with
ember server --proxy http://localhost:9090/api every time can get tiresome, you can get around this by changing the npm start command in the package.json file that is created with your ember-project."scripts": {
"start": "ember server --proxy http://localhost:9090/api",
"build": "ember build",
"test": "ember test"
},
Then start your project with the
npm start command instead.Another way to make your life easier is to not build your client in Visual Studio, it's nice for ASP.NET and C# and the like, but, at least at the time of writing this, it leaves a lot to be desired when it comes to JavaScript programming, and working with generators like ember-cli. I'd recommend using something like Webstorm, or even just using something super-lightweight like Atom or Sublime text. These alternatives don't require you to do things like refreshing the solution explorer for each file change ember-cli makes, and hiding and showing files that aren't attached to the project. Maybe VS2015 will fix all of this, I haven't tried it yet.
This solution may not be ideal (I really hope theres an easier way!) but I think it's pretty workable and I haven't run into any problems as of yet while building a large ember app using this workflow.
Next on my list, do more integration testing!