debugging the issue
What about in your network
tab in the developer console? Do you see the request for /api/rentals.json
being made successfully?
The next step would be to put a breakpoint into the model hook and inspect the parsed
var to see if it’s actually fetching the JSON properly and parsing it properly.
If all that looks good I’d next look at my template code and make sure that the structure the template is expecting matches the data that is coming from the model hook.
And if that looks good you could inspect the component that’s rendering each rental to make sure it’s getting the right props passed.
servers and ports
As to your question about servers and ports I’ll try and explain it all at a high level and hopefully that will help, and feel free to ask any follow ups if something isn’t clear…
First off, Ember is a SPA (single page application) framework. This means that the entire ember app is captured in one (very dynamic) HTML document and its attending javascript and css files. When an ember app is deployed in production the app itself is just a few static files that sit on a static file server somewhere. When you “build” an ember app (which is a prerequisite step to running ember s
etc) it smashes all your source files together into a few files and places them in dist
(by default). If you look there you’ll probably find an index.html
file, some javascript and css assets, and a few other goodies. But again these are all static files, meaning any static file server can serve them.
So one common point of confusion is what the ember “server” is for. The ember server is not meant to handle any sort of typical API responsibilities like connecting to a database or serving dynamic HTTP requests, etc. It’s main purpose is just to serve static files from your project directory in development. You wouldn’t want to use the ember server for actual production deployment as it’s probably not robust or secure enough for that sort of thing. So when we refer to the ember server it’s just a little node script that serves your static files for you while you’re developing as a convenience. In the tutorial you’re mocking an “api” by using static files, but that only really works because the fixture files are static.
The vast majority of real world ember apps will also leverage a backend API of some sort. For example at my company we have a full API built in Ruby on Rails among other things. Our Ember app is hosted in Redis and served via Rails too but you could host it in Amazon S3, Apache, literally anything that could serve static files. The ember app itself doesn’t have to be served by the API server. So then a client browser makes the request for your app, downloads the static assets that make up your app, and “boots” it. Then your app (usually) starts to make requests to your API server. Anyway point being the API server is a separate thing entirely.
During development you’ll usually have your API server running on one port, spin up your ember server (port 4200 by default) perhaps proxied to your API server port, and then visit localhost:4200
in your browser. That request is served by your ember server which just gives the browser your static app assets, and then (if you’re using proxy) proxies your apps requests to the API server.
Mirage of course is another option for using a “fake” server. Note that it does not actually exist outside of your Ember app and just intercepts the requests that are made before they “leave” your browser. It’s an incredible tool for both testing and for prototyping apps. However you wouldn’t want to use it in production in most cases because if nothing else there is no persistence (the mirage database is all in your browser memory so if you refresh the page the server is wiped out).
So anyway, that’s a lot of text but the broad strokes are:
- ember server isn’t meant to serve data unless it’s static file data like in the tutorial, it’s mainly a convenience for development purposes
- mirage is a great solution if you’re prototyping out an app that doesn’t have a backend yet, or writing tests (where you want isolation from the actual backend) or want to get up and running with fixtures really fast
- if you want persistent database-backed data layer you’ll need an API server at some point. Ember Data gives you incredible power and flexibility over matching any backend API to a declarative powerful data store on the front-end, and you can also opt out of Ember Data and use other data fetching/caching methods.