Don't use React starter kit (especially Intl branch) on production. low performance will kill your servers

[dzek69]

A story about using a boilerplate for React server side rendering...

So I wanted to put a site made with React live. Nothing fancy - single landing page. One page, 10 languages supported. I've analysed all the possible choices and found RSK to look as best possible choice, but still not very good.

The only big con was: ugly code. The ˋlet's put all init stuff in huge server.js/client.jsˋ approach was hurting my eyes, but hey, I'll fix it and I wanted to release the site asap.

I'll skip all the parts I don't like because of my favourite way to do stuff and all the small issues that made programming annoying.

Lets go straight to the killing servers parts:

1. GraphQL

By removing GraphQL part I was able to handle twice as many requests to my page in one second (measured on actual production server, under stress test). Looks like putting JSON decoding locale strings in each request is a huge bottleneck even for one page landing page. Just about 100 strings were used. Imagine using that on big site with thousands of strings to translate.

2. Improper handling of routing (already mentioned in some issue).

If you have some 404's on your site - ... they will fall into actual subpages routing handling and the whole app will be initialized just to serve you 404 result. YES! Translations strings will be used on 404's too (which itself is ok) so single page + 5x 404 takes about whole second from your server time (measured on dev machine, not actual server) and I'm talking only about JSON parsing part, not the whole app stuff.

This weren't all the issues, but most concerning ones.

Yeah. I know. You'll call me hater. You'll tell I'm just another person that uses OS software and expects everything for free not giving anything back. Ok, that's fine. I prefer giving back to community by teaching, not by releasing OS code (I'm gonna to change that btw).

Just warn your users that the stuff you are offering isn't tested, has low performance because nobody actually measures that and has low quality code even when using modern dev stack.

Don't let others make my mistake. RSK IS FINE, but as playground, nothing more.

[frenzzy]

Can you describe how you solve performance problems in your application? Personally I don't use React Intl in my projects but it would be nice to hear about edge cases.

Btw, in my production apps based on master branch of RSK I have 40-80ms TTFB:

There are configured Nginx in front of Node.js application with proper caching. For translations I use very simple handmade i18n-loader. (alternatives: one, two)

[buildbreakdo]

@dzek69 Not enough methodology, system, or config information for this to be useful or actionable. Performance conclusions are relative, what is your benchmark?

[langpavel]

@dzek69 feature/react-intl is used as base on production for some small sites. Of course, this is mostly example of doing things, but it should perform well.. And yes, It is possible do more optimizations ;-) If you think that react-intl is bottleneck for server side rendering, you can divert locale loading code path for server and client. You can also implement caching of locale files after first request, this can save one file read request per full page refresh request and give great performance boost...

After first page load, users should not need server any more, except fot GraphQL or REST API or what you fetch data, so first check if you are using kit properly, configure caching etc...

And of course, make sure you deploy production build on server: yarn build -- --release

[langpavel]

@dzek69 Ad 10 languages. It should not matter if you translate 2 or 200 languages, it always follow same code path, only with different dictionary ;-)

[fatal10110]

Just serve translations as static files (nginx) on client, on ssr read the file content..

@langpavel you are right but there is a difference if you have 10 messages or 2k messages ..

this is mostly example of doing things

There are a lot of missing examples, there are no "containers" that uses connect from redux package, also there are no examples how to do async data request, in routes you are fetching data synchronously (using await) but how to do it async with proper handling on the ssr and title translations for example :)

[langpavel]

@fatal10110 Ok, right, connect is from react-redux..

If you are not willing to search and learn from top results all the time, you are welcome to write short wiki or better, you are welcome to open PR. You can also open discussion on gitter. All is mentioned in README.

We need more people writing docs, participating people, with real observations and real experience. Yes, we need support. I'm really open to help everyone who has real tasks with appropriate amount of funds -- buy me beer for this answer, yeah! :smiling_imp: We are doing this thing for everyone who don't want start from scratch. We are not challenging frontier. You see.. all of this is only interest of us equaled only by our experience. So, thanks for your observation, what is you recommendation @dzek69?

We have open Wiki I believe, everybody there have a little amount of time to offer, sometimes you can buy more and profit from.. but sorry, if you discover only this and you giving it up, you are doomed by yourself. :beers:

[langpavel]

Check now, it cannot be more performant :-) Just kidding, but Apollo will prevent unnecessary re-fetching..

[carlosconnected]

Is there a list of webapps in production using this RSK?

[buildbreakdo]

@carlos-peru Don't think so, personally use it over at pholder.com, serve thousands daily. Check out Peru: pholder.com/Peru

[holgersindbaek]

I'm not sure why this issue is still open. I'm using RSK as the base for my solitaire site https://online-solitaire.com/, which serves tens of thousands of pageviews a day and I've never had any issues with performance.

[dzek69]

@holgersindbaek Tens of thousands pageviews a day could not be enough (we probably had tens of thousands per hour if not more, very big company and popular new product) or/and things could've changed, as it seems this project is still updated.

However GitHub Issues are kind of ignored as, like you've noticed, this is still open and without offical reply

Looking back at my post - it is too aggresive, but I was probably too tired and angry trying to fix the issues and then rewrite the page using something else. Company had spent thousands $ on servers, trying to keep up with serving the website. We had a lot of pressure to release new stuff ASAP and then because of bad performance and costs a lot of pressure to fix it.

[damianphung]

@dzek69

curious to know what you did to move forward in your situation. Was it adding more $ on servers in the end?

[dzek69]

@damianphung at first we increased $ and tried to fix as many bottlenecks as possible (removing graphql for example, which as described initially sped up the website by factor of 2) then we have migrated to next.js

[ulani]

@dzek69 thank you very much for crating this issue! Unfortunately, we have close it due to inactivity. Feel free to re-open it or join our Discord channel for discussion.

NOTE: The main branch has been updated with React Starter Kit v2, using JAM-style architecture.