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

Can we Server-side Render a Different UI Framework in a Phoenix App? #85

Closed
nelsonic opened this issue Jun 4, 2020 · 2 comments
Closed
Assignees
Labels
discuss Share your constructive thoughts on how to make progress with this issue help wanted If you can help make progress with this issue, please comment! question A question needs to be answered before progress can be made on this issue technical A technical issue that requires understanding of the code, infrastructure or dependencies

Comments

@nelsonic
Copy link
Member

nelsonic commented Jun 4, 2020

The default Phoenix HTML template engine (EEx) has fantastic performance. All templates are compiled to BEAM bytecode and executed as cached functions so rendering takes 1-4 µs.

"After compilation, templates are functions. Since Phoenix builds templates using linked lists rather than string concatenation the way many imperative languages do, one of the traditional bottlenecks of many web frameworks goes away. Phoenix doesn’t have to make huge copies of giant strings." ~ Chris McCord, Programming Phoenix 1.4

1 µs is one microsecond is a millionth of a second!
For reference the average template rendering time for a server side rendered (SSR) React.js App is 50 ms (milliseconds). It takes 20-50 thousand times longer to render a React.js template!! see: https://malloc.fi/performance-cost-of-server-side-rendered-react-node-js
Obviously, if the response time for that single request is still below 100-250ms (total round trip) the end user won't feel the React "tax", but it has a real impact on concurrency. Given that rendering requests block the Node.js event loop, it means that node.js instance can only serve 20 requests per second! (1000/50 = 20) That's an insane bottleneck to apply to your app!
Since Node.js can only run one process per machine core, even if you have a 8-core server running 8 instances of your Express App, you will still only be able to serve 160 requests per second! This is "fine" for most Apps that don't have many users, but which dev deliberately builds an app that can be crashed simply by being "too popular" on HN/Reddit/ProductHunt ?!
Every day I thank my lucky stars that I made the choice to ditch Node.js and switch to Elixir!

Anyway, while researching this issue I looked at https://github.com/revelrylabs/elixir_react_render (read all the code) and it uses the nodejs https://github.com/revelrylabs/elixir-nodejs to invoke the Node.js module that does the rendering. See: mix.exs#L43

@nelsonic nelsonic added help wanted If you can help make progress with this issue, please comment! question A question needs to be answered before progress can be made on this issue discuss Share your constructive thoughts on how to make progress with this issue technical A technical issue that requires understanding of the code, infrastructure or dependencies labels Jun 4, 2020
@nelsonic nelsonic self-assigned this Jun 4, 2020
@nelsonic
Copy link
Member Author

nelsonic commented Mar 4, 2022

With LiveView https://hexdocs.pm/phoenix_live_view/ this is less relevant ... 💭
Simon made a good example/tutorial app: https://github.com/dwyl/phoenix-liveview-chat-example 💬
will be trying to do the same shortly ... dwyl/sleep#53 😴 ⏳

@nelsonic
Copy link
Member Author

Our MVP: dwyl/mvp |> mvp.fly.dev uses the PETAL stack #87. We no longer need a different UI framework. 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Share your constructive thoughts on how to make progress with this issue help wanted If you can help make progress with this issue, please comment! question A question needs to be answered before progress can be made on this issue technical A technical issue that requires understanding of the code, infrastructure or dependencies
Projects
None yet
Development

No branches or pull requests

1 participant