Hey @Grahamcox82, ember serve isn’t really meant to be used in any “server-side” sense, nor is it (to my knowledge at least) meant to be used in production. The purpose of ‘ember serve’ is to run your Ember app locally, watch for file changes, rebuild the app, refresh the browser, etc and all that is desirable for development ease. Essentially it’s acting as the server that is serving your Ember app, but not the “backend” API server. Typically a production deployed Ember app will be built (ember-cli runs through a ton of steps that smashes your ember app into a few files including an index.html, an app code javascript file, a vendor javascript file, and app code and vendor code css files, and a couple other supporting files). Those files are then typically uploaded to something like S3, etc. and served via a basic web server. For example, the app that I work on is an Ember app which we deploy to S3 configured with cloudfront, etc. Then our API is a distributed Scala app hosted in Amazon EC2. So the browser hits our url which requests data from cloudfront/S3 to load the ember app files. Once those are downloaded and loaded in the browser the ember app “boots”, and then connects to the API server. So there are two servers involved essentially. The ‘ember serve’ command is meant to (for development purposes only) act as the first server, the one that serves your static compiled ember app and related assets to the web browser.
Ember is a SPA framework, front-end only. It is for creating client apps. Thanks to Ember Data customization It can be used with pretty much any web API. Unfortunately if you’re not already a server-side or backend developer, it’s a LOT of work to then learn a backend framework/language, design a server, and learn about server config/deployment/security, etc. Rails seems like a great choice for server framework, especially when working with Ember, but you could use anything really: node, django, etc.
Another thing you could do, depending on your needs, is use something like Firebase. Firebase is a collection of services (now owned by Google) including authentication and most importantly the “real time database”. You can use Firebase as a backend for an Ember app, and it can be 100x easier than writing your own server stack. Again, this depends on your needs. One of the primary criticisms of Firebase is that it’s more or less just a database, and you can’t really write server-side logic (you sorta can now via cloud functions, but that’s not really the point) so you end up putting a lot of what would be server-side login in your front-end app. I personally think firebase is great, and if your app is fairly low-complexity it may be a great fit for firebase. To use firebase you want to install emberfire which provides all of the requisite ember data customization code for you.
Anyway, hope that helps clear things up a little bit for you. In summary, if you want to have non-static data in your Ember app, you’ll need a backend of some kind. Ember does not provide tools for the backend at all, it’s meant to be front-end framework only. So you’ll want to do some research and decide what fits your needs/requirements/resources best. If you want a fairly straightforward app that doesn’t require a lot of custom data processing, I’d definitely look into firebase first. Server development is a huge, broad topic with a lot of rabbit holes and lots of choices and paradigms and opinions, but if you have any more specific questions about Ember, questions about server-side frameworks or recommendations, Firebase, or pretty much whatever, feel free to ask in this thread or in a new one. And good luck!