I'm wrapping up my Ember application and I want to figure out the best practice for handling the public site (/
, /about
, /faq
, etc). Ideally the Ember JS and the majority of the app itself wouldn't be loaded.
There are a couple options, but I'd like to know the best practice.
Option 1 - Part of the app
Just make the public pages templates within ember-cli.
Pros:
- Same asset pipeline
- Single delivery of your entire site
Cons:
- How do you have two base templates? One for the public site and one for the app itself. Ideally I'd be able to have different nav bars for each part. Everything inherits from the
application.hbs
template but I don't want to put conditionals in there to handle the two nav bars. I also don't want to overwrite every other page in my app to put it under a different template (/app/*
). - The entire app would be loaded the first time the user goes to the page (only gets slower as the app gets bigger).
Option 2 - Part of the public folder
Create static HTML in the /public
folder.
Pros:
- Same asset pipeline
- Single delivery of your entire site
- Not loading the entire app for public pages
Cons:
- You have the write the entire HTML for every page. This doesn't allow for quick development.
- No template system. As the public site grows it's best to have a template so you can easily change the nav bar on all pages.
- Not sure how to handle
/
since ember-cli wants to handle that url, but I'd want it to be apart of the public site. - Adds a lot of junk to your
public
folder since you'd need to addabout/index.html
for good urls.
Option 3 - Separate from the ember-cli project/app
Create a nanoc site or some other statically generated site and deliver it for your public pages.
Pros:
- Have properly layouts for public site
- Separation of assets
- Not loading the entire app for public pages
Cons:
- Need to figure out how to properly deploy separate apps on the same domain (putting ember-cli under
/a/
is easy, but if I deploy to heroku how do I serve up multiple heroku apps on the same domain?). - How should
/sign-up
and/sign-in
be handled? Public site with public site chrome, or web app with a signed out state (not ideal).
Aucun commentaire:
Enregistrer un commentaire