Aurelia: [RFC] SSR / Aurelia http-server package (placeholder)

Created on 7 Oct 2019  路  3Comments  路  Source: aurelia/aurelia

馃挰 RFC

馃敠 Context

馃捇 Examples

API Needs more feedback RFC Extensibility SSR

Most helpful comment

Ideally, the implementation of SSR would be a little more robust than the vCurrent implementation. The way in which vCurrent works, it is lacking a lot of features and is quite fickle. A lot of the problems I have experienced in Aurelia and helped others with is server-side rendering.

Some of the painful areas of the current implementation I have experienced include;

  • Issues around debugging. When things break, the server doesn't seem to return any meaningful error messages or ways of stepping through to see what has broken (the server just hangs or gives a non-descript issue, most times you will just get a timeout with no information at all)
  • Lack of support for SEO features such as meta tags (description, keywords, social media open graph tags)
  • Issues with using libraries only meant to work within the browser breaking the SSR functionality, requiring if statement checks around numerous blocks of code and conditionally loading libraries which rely on globals such as window.
  • Memory leaks. This isn't an Aurelia-specific problem, it seems many SSR implementations in other frameworks and libraries thanks to Node are prone to memory leaks.

It is to the point where I will avoid using SSR in vCurrent if I can. It's a bit of a nightmare to work with, mostly in preexisting Aurelia codebases because the work you have to do to get it working is immense and a huge time sink. I have tried hacking together my own solutions with things like Puppeteer, but have run into other issues going down that path as well.

Ideally, it would be a "nice to have" for the SSR functionality to support different forms of rendering. Right now, vCurrent SSR is primitive in that it effectively just renders all of the HTML and returns it. The ReactJS DOM Server API exposes some useful methods for this:

A super nice to have would be the ability to return a stream like this React DOM Server method: https://en.reactjs.org/docs/react-dom-server.html#rendertonodestream

While rendering pages on demand is a crucial SSR feature, the ability to call an API to be able to generate static HTML pages (think a static site generator) would be another beautiful addition to the overall server-side rendering functionality.

Understandably, being a framework and not a library, some of these things are not that trivial and would possibly require a bit of work. Even just a fast and somewhat configurable SSR implementation would be an improvement.

I thought I would share my experiences with vCurrent SSR, so we do not go basing v2 SSR off of the existing implementation. Whatever we end up coming up with, the ideal would be to start from scratch.

All 3 comments

Ideally, the implementation of SSR would be a little more robust than the vCurrent implementation. The way in which vCurrent works, it is lacking a lot of features and is quite fickle. A lot of the problems I have experienced in Aurelia and helped others with is server-side rendering.

Some of the painful areas of the current implementation I have experienced include;

  • Issues around debugging. When things break, the server doesn't seem to return any meaningful error messages or ways of stepping through to see what has broken (the server just hangs or gives a non-descript issue, most times you will just get a timeout with no information at all)
  • Lack of support for SEO features such as meta tags (description, keywords, social media open graph tags)
  • Issues with using libraries only meant to work within the browser breaking the SSR functionality, requiring if statement checks around numerous blocks of code and conditionally loading libraries which rely on globals such as window.
  • Memory leaks. This isn't an Aurelia-specific problem, it seems many SSR implementations in other frameworks and libraries thanks to Node are prone to memory leaks.

It is to the point where I will avoid using SSR in vCurrent if I can. It's a bit of a nightmare to work with, mostly in preexisting Aurelia codebases because the work you have to do to get it working is immense and a huge time sink. I have tried hacking together my own solutions with things like Puppeteer, but have run into other issues going down that path as well.

Ideally, it would be a "nice to have" for the SSR functionality to support different forms of rendering. Right now, vCurrent SSR is primitive in that it effectively just renders all of the HTML and returns it. The ReactJS DOM Server API exposes some useful methods for this:

A super nice to have would be the ability to return a stream like this React DOM Server method: https://en.reactjs.org/docs/react-dom-server.html#rendertonodestream

While rendering pages on demand is a crucial SSR feature, the ability to call an API to be able to generate static HTML pages (think a static site generator) would be another beautiful addition to the overall server-side rendering functionality.

Understandably, being a framework and not a library, some of these things are not that trivial and would possibly require a bit of work. Even just a fast and somewhat configurable SSR implementation would be an improvement.

I thought I would share my experiences with vCurrent SSR, so we do not go basing v2 SSR off of the existing implementation. Whatever we end up coming up with, the ideal would be to start from scratch.

I have once created a library for aurelia, aurelia-meta, in which I tried to integrate meta tags into route engine, and beside add functionality like the this one in angular. I am not sure tho whether meta tags are related to SSR or routing since each page/route could have predefined meta tags as well as dynamically generated tags.

I would like to second the usefulness of being able to generate static HTML pages so that Aurelia could be used for JAMstack sites. Having support for both SSR and static HTML export would make Aurelia able to compete with the other frameworks out there.

Was this page helpful?
0 / 5 - 0 ratings