Will someone please help me?

1

First off let me say that I have read this forum since December and I have noticed that nearly all of you are awesome devs, I rarely ask for help but I’m at the point now to where I literally haven’t a clue of what to do. I have searched for days on trying to get my api to hook up to ember-data’s RESTAdapter. I have tried putting Ember in the root folder of my Laravel App and though I could get the application to load up, I coulnd’t get Ember to show my data from the API and I got a bunch of content security violations. I posted another thread about it on here in detail. Anyway,

Now I am left with …

  1. Should I put my Laravel App (api) on Heroku and develop my Ember app locally like I normally do. Then when I it comes time to deploy put it on Heroku as well. or
  2. Create a new Ember app in my Sites directory where all my frontend stuff gets built and then create my Laravel App (api) in my Projects Directory -where my server side gets built and uses vagrant- I have no idea on how to get vagrant to work with Ember CLI, What I am confused on is that both Ember and Vagrant use localhost so how will Ember data know which host the api is in?

I am sincerely asking for some real advice on getting these two technologies to work. I love them both and want to use them both and can’t wait to learn a lot about Ember. I just need some advice from you guys because you all seem like you know what the heck your doing. If you do reply thank you so so much. I really do appreciate any feedback on this matter. Every article I find is either outdated or uses rails.

2

While I’m sure it can be done, no one seems to have a very good time (even with rails) deploying their front-end solution from their back-end solution. Architecturally, I think it’s a better practice to separate your app server from your API anyway. Integrating with a backend gets easier when you start treating the backend like you don’t own it (even though you often do).

What I would recommend is that you make use of the environment variables (in /config/environments.js) to store different connection information for your local and production environments. You can use http-mocks in Ember CLI to simulate your API for quick development, possibly have an “integration” environment where you are connecting to a Heroku app for API requests, and a production environment which uses all of your production servers. In your Ember Data adapter, you can import the config file and reference a ENV.APP.host variable that will switch the host based on environments.

3

  1. I agree with separating the frontend from the backend. While it may take somewhat longer to set up and you have to make sure that breaking changes are in sync (or that you use a versioned API, but that makes more sense when you have a public API that is already deployed), it saves you a lot of maintenance trouble down the road.

  2. If you start your Ember app in development with the --proxy localhost:9292 option, all API requests will be proxied to the API at that location (you can of course substitute whatever host/port combination you want, you can also run it against a staging version etc)

  3. For deployments, the host must be included in the generated JS output. This can be done by setting values in config/environment.js. That file will be read when you run ember build, but won’t end up in your final app directly. You can set environment specific data here, e.g.

    if (environment === ‘staging’) { ENV.APP.API_HOST = ‘http://www.myapi.com:8065’; ENV.APP.SOME_HEADER = ‘header’; }

Now, when you run ember build --environment=staging, those values will end up in your build output (but not any values for other environments).

You can then use those values in other files, e.g. in your ApplicationAdapter:

import ENV from 'yourappname/config/environment';

export default DS.RESTAdapter.extend({
  host: ENV.APP.API_HOST,
  headers: {
    'X-SOME-HEADER': ENV.APP.SOME_HEADER
  }
}

NB: The contents of ENV will be publicly visible to anyone who can access the frontend. If you need some sort of API key for your staging environment, for example, you absolutely must protect access to the staging frontend as well (as well as to your codebase).

  1. You can indeed use http-mocks to prototype your API before building the backend, although I much prefer ember-cli-mirage.

  2. You will also need to enable CORS for your API in deployment.