Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Road to 1.0 #98

Closed
17 of 38 tasks
tomdale opened this issue Jan 27, 2016 · 32 comments
Closed
17 of 38 tasks

The Road to 1.0 #98

tomdale opened this issue Jan 27, 2016 · 32 comments
Milestone

Comments

@tomdale
Copy link
Contributor

tomdale commented Jan 27, 2016

This is a quest issue tracking the features and bug fixes needed to consider FastBoot ready for mass consumption. Expect this list to grow over time. All discussion and details should be broken out into separate issues/PRs; this issue is just for coordinating and tracking work.

Release Plan

Nice to Have

Please chime in with anything I've missed.

@tomdale tomdale added this to the FastBoot 1.0 milestone Jan 27, 2016
@danmcclain
Copy link
Member

What about appending requested host to absolute paths in ajax requests

@tomdale
Copy link
Contributor Author

tomdale commented Jan 27, 2016

@danmcclain Added #101 to track that.

@taveras
Copy link

taveras commented Jan 29, 2016

How about being able to control over the /robots.txt response served from fastboot?

@tomdale
Copy link
Contributor Author

tomdale commented Jan 30, 2016

@taveras It's just an Express middleware, so you can add your own handling for arbitrary endpoints. We should try not to let FastBoot turn into a generic HTTP server.

@tomdale
Copy link
Contributor Author

tomdale commented Feb 3, 2016

Per this week's meeting:

  • @ronco is working on adding support for head.hbs to render <head> elements
  • @rwjblue is working on a change to Ember CLI so that config is written to a JSON file
  • @cibernox is updating his addon to work in FastBoot and collecting a list of pain points for dual testing an addon in both scenarios
  • @tomdale will work on exposing the Express request as FastBoot.request
  • @RuslanZavacky is investigating getting good performance out of the Googlebot and is working on a PR that allows disabling <script> tags from FastBoot's HTML page.

@jpadilla
Copy link
Contributor

jpadilla commented Feb 3, 2016

I also started working on #99 😃

@tomdale
Copy link
Contributor Author

tomdale commented Feb 3, 2016

If you're interested in helping out, join us in #fastboot in the Ember community Slack.

@sebyx07
Copy link

sebyx07 commented Feb 4, 2016

it would also be nice at first to have cache headers in the response

ember fastboot --cache-headers 15000

before we have better access to headers

@tomdale
Copy link
Contributor Author

tomdale commented Feb 4, 2016

@sebyx07 It's just an Express middleware, you can add whatever headers you want.

@MiguelMadero
Copy link

@tomdale what about "hydrating" or making the fastboot app into a normal emberApp after everything is loaded?

@danmcclain
Copy link
Member

@MiguelMadero I think that hydrating is blocked until Glimmer 2.0 lands, I'll let someone else confirm

@tomdale
Copy link
Contributor Author

tomdale commented Mar 21, 2016

@MiguelMadero @danmcclain Confirmed

@MiguelMadero
Copy link

Thanks for clarifying.

@danmcclain
Copy link
Member

Support multi-stage (browser → FastBoot) build with asset rewriting, so FastBoot index.html points at browser build, not FastBoot build

@tomdale Your latest PR achieves this, right?

@tomdale
Copy link
Contributor Author

tomdale commented Mar 26, 2016

@danmcclain Confirm, good catch!

@coladarci
Copy link

Wow - when this is finished, Ember will really be able to DoItAll™️!
Realllllly want to start a new project w/ fastboot but am scared that w/out Hydration landing relatively soon, it won't be the right decision and we might be left in a tough spot. Any ballpark ideas of when hydration will be added? I looked for a Glimmer 2.0 roadmap and couldn't find one.. Thanks for all the work on this - really a game-changer for Ember.

@hhff
Copy link

hhff commented Apr 3, 2016

@coladarci - I think it's a safe bet - while fastboot doesn't technically 'rehydrate', it does 'redraw' the application once the browser JS payload hits. It kinda clicks into place. Works really well for the most part 👍

@coladarci
Copy link

Yeah I noticed that, which is great. That said, that means for ~1.5s the actions on the page don't do anything, which is a bit of a blocker for my application :) I'd love to know where to follow the Glimmer 2.0 progress so I can get a rough idea of the blockers and how actively they are being addressed. We'll probably use ember for the new project w/out fastboot but checking it along the way to make sure there are no surprises, then hope we can flip it on before the launch.. I was thinking about a hybrid model where I remove a body class w/ the booted ember app so I can sort of gray out the body until the app is fully loaded; will give the end user immediate feedback and excitement but not render a bunch of busted actions for an awkward few seconds.

@tomdale
Copy link
Contributor Author

tomdale commented Apr 4, 2016

@coladarci Yeah, one thing I'd like to do is automatically add an ember-fastboot class name to the <body> that gets removed once the app boots up. That would allow people to easily style interactive elements as disabled until the JavaScript has finished booting.

@Cryrivers
Copy link

@tomdale So 'hydrating' feature will come with Fastboot 1.0 and Ember 2.7?

@tomdale
Copy link
Contributor Author

tomdale commented Apr 4, 2016

@Cryrivers I suspect it will not be in by FastBoot 1.0, but it's largely gated on Glimmer 2 work.

@oligriffiths
Copy link

@tomdale Am I right in thinking, according to the checklist above, that fastboot is essentially code ready, but needs the associated docs, website, watch, etc, sorting out?

@tomdale
Copy link
Contributor Author

tomdale commented Sep 5, 2016

@oligriffiths Yes, we are very close. The last thing gating a 1.0 release is some performance improvements to the build process. After a lot of core team discussion, people were hesitant about the almost-doubling of build times that installing FastBoot adds to the boot process.

@stefanpenner had some great ideas for how we can avoid the extra cost, and I'm hopeful we can get those implemented soon. They will also clean up some of the monkeypatches to Ember CLI internals we have to do at the moment, and should address other usability concerns like #246.

@stefanpenner
Copy link
Contributor

@stefanpenner had some great ideas for how we can avoid the extra cost, and I'm hopeful we can get those implemented soon. They will also clean up some of the monkeypatches to Ember CLI internals we have to do at the moment, and should address other usability concerns like #246.

related: #264 (comment)

@kratiahuja
Copy link
Contributor

@tomdale Here is an RFC that Stef and I worked on for fixing the fastboot builds. I would prefer to hold up 1.0 release until this is fixed since this a fully backward incompatible change to current fastboot ergonomics. If we don't hold, we will need to jump to Fastboot 2.0 and the experience may not be good.

I will be working 100% of my time on that RFC and some other fastboot OSS stuff so I can get this out soon enough.

@simonihmig
Copy link
Contributor

Could we get an update on what is still blocking a 1.0 release?

I guess #356 is the major blocker here, which is hopefully landing soon, anything else that is not listed in the above to do list?

From that list, I think several items have not been updated yet...

Website Updates

Those things seem to have been addressed already, at least in some form. Anything missing there? Can help if needed...

Verify Node 0.12 compatibility

This can be dropped, right?

@kratiahuja
Copy link
Contributor

there is one more item: fixing this issue #264 . There is a solution to address this and @leitsubomi is going to look at implementing it.

@fotinakis
Copy link

I'm curious, is there a security evaluation/penetration testing planned for fastboot v1? Has anyone attempted to break it?

I'm very excited about fastboot, just as a user I'm concerned about understanding the security implications of moving from a purely static-file serving production environment (which is relatively easy to serve and secure) to one where user requests will interact with a full dynamic server environment with node + middleware, which of course comes with a completely different security footprint.

@shahkashani
Copy link

Any word on whether rehydration will make it into 1.0, now that Glimmer 2.0 is out?

@danmcclain
Copy link
Member

#360 supersedes this issue, closing this as it is no longer up to date.

Rehydration is not currently a 1.0 blocker, but that doesn't prevent it from landing during the 1.0 series

@ghost
Copy link

ghost commented Sep 18, 2017

@danmcclain I haven't been able to find any information with how ember + fastboot deals with rehydration. Does the app just rerender from scratch in the background and replace the existing dom?

@danmcclain
Copy link
Member

@citizenconn Rehydration has yet to be implemented, so it has to rerender the app from scratch (or some from the shoebox) then replace the dom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests