How do we live a year without sprockets and with react
Hello!
We in taaasty.ru have been living for a year and a half on react-e and almost a year without sprockets. This is so cool, I want to share. For one thing, I’ll tell you how react works with rails in prerender mode.
Much has been said about this technology. I just want to confirm, yes, she is beautiful. When I came to the project, he was in the “let's fix these bugs, which came out from the fact that he repaired this one ”. During the frontend, the desires of cool chips were so much that it became immediately clear - we could not take into account all the possible nuances of behavior in JS, and still parallel and correct the bugs in the Legacy code without some cardinal solution. And React solves this problem completely.
')
First, we connected react-rails and made components in the rail environment on coffee. The following problems quickly emerged:
1. JS code is big. Sprockets brake. Compilation wait changes were becoming more and more tedious.
2. The front-tender had to adjust ruby on rails, and in spite of the general environment in vagrant , these are unnecessary actions, a waste of time.
3. The front-end has its own set of technologies - gulp, webpack, and so on, its own packages, which you will not plug into the rails.
4. In addition to the front-end html, the layout designer also works, and sometimes the designer. They generally do not have to rail. And also the layout periodically needs to be shown to the customer and it is easier to do on static ftp pages than to run rails for this.
In general, everything went to ensure that the frontend is a separate project. So did. All React and JS moved to a separate repository (they left it open) - github.com/taaasty/web-static
The frontrunner and coder are working with their technology stack, do not depend on the back-bend, they do their quick builds. They can run the frontend application and poison it on the vendor or the test server of choice.
Since the front repository was left open, we connected a free travis for builds, and made a script to post the finished demo build on gh-pages - taaasty.imtqy.com/web-static so you can always see the latest working version of the layout and scripts.
At this stage, began to better understand the meaning of the saying "divide and conquer."
Since all the JS and CSS are built in a separate repository, the need for assembly and sprockets (creepiness) is completely gone in the rails. Static files are connected to the project as git submodules:
In the front of the repository there are ready-made assembly files for styles and javascript, and we request them directly from html:
Now, when deploying, there is no precompilation (assets: precompile is not needed), everything is already laid out. Deploy duration decreased from 4-5 minutes to 15 seconds.
And how well it became to the buckers - I inserted the component, gave it the parameters of the desired structure, and you don’t have any hemorrhoids with html and JS. All this has already been decided at the front. In fact, the backend has become such a big API - api.taaasty.com
Everyone who finds out that we have the whole front in the reactor, first of all asks, so how is the prerender? Yes, great, it works with a half-kick, all pages are given with a ready-made layout.
In ruby, there are two working engines for javascript execution (and component pre-rendering). This is therubyracer (uses the libv8 library) and nodejs (actually starts nodejs and gives it the code for execution).
We settled on therubyracer. At the moment, it renders 2-3 thousand components per minute. More than a year the flight is excellent. react-rails remained in the project and performs only the functions of a pre-tender.
We in taaasty.ru have been living for a year and a half on react-e and almost a year without sprockets. This is so cool, I want to share. For one thing, I’ll tell you how react works with rails in prerender mode.
ReactJS
Much has been said about this technology. I just want to confirm, yes, she is beautiful. When I came to the project, he was in the “let's fix these bugs, which came out from the fact that he repaired this one ”. During the frontend, the desires of cool chips were so much that it became immediately clear - we could not take into account all the possible nuances of behavior in JS, and still parallel and correct the bugs in the Legacy code without some cardinal solution. And React solves this problem completely.
')
First, we connected react-rails and made components in the rail environment on coffee. The following problems quickly emerged:
1. JS code is big. Sprockets brake. Compilation wait changes were becoming more and more tedious.
2. The front-tender had to adjust ruby on rails, and in spite of the general environment in vagrant , these are unnecessary actions, a waste of time.
3. The front-end has its own set of technologies - gulp, webpack, and so on, its own packages, which you will not plug into the rails.
4. In addition to the front-end html, the layout designer also works, and sometimes the designer. They generally do not have to rail. And also the layout periodically needs to be shown to the customer and it is easier to do on static ftp pages than to run rails for this.
In general, everything went to ensure that the frontend is a separate project. So did. All React and JS moved to a separate repository (they left it open) - github.com/taaasty/web-static
The frontrunner and coder are working with their technology stack, do not depend on the back-bend, they do their quick builds. They can run the frontend application and poison it on the vendor or the test server of choice.
Since the front repository was left open, we connected a free travis for builds, and made a script to post the finished demo build on gh-pages - taaasty.imtqy.com/web-static so you can always see the latest working version of the layout and scripts.
At this stage, began to better understand the meaning of the saying "divide and conquer."
Sprockets
Since all the JS and CSS are built in a separate repository, the need for assembly and sprockets (creepiness) is completely gone in the rails. Static files are connected to the project as git submodules:
$ cat .gitmodules [submodule "vendor/static"] path = vendor/static url = https://github.com/taaasty/web-static.git branch=develop $ ag vendor/static config config/application.rb 40: config.assets.paths << Rails.root.join('vendor/static/dist/stylesheets') 41: config.assets.paths << Rails.root.join('vendor/static/dist/scripts') In the front of the repository there are ready-made assembly files for styles and javascript, and we request them directly from html:
= javascript_include_tag 'desktop.production.js' = stylesheet_link_tag 'desktop.production.css' Now, when deploying, there is no precompilation (assets: precompile is not needed), everything is already laid out. Deploy duration decreased from 4-5 minutes to 15 seconds.
And how well it became to the buckers - I inserted the component, gave it the parameters of the desired structure, and you don’t have any hemorrhoids with html and JS. All this has already been decided at the front. In fact, the backend has become such a big API - api.taaasty.com
react-rails
Everyone who finds out that we have the whole front in the reactor, first of all asks, so how is the prerender? Yes, great, it works with a half-kick, all pages are given with a ready-made layout.
In ruby, there are two working engines for javascript execution (and component pre-rendering). This is therubyracer (uses the libv8 library) and nodejs (actually starts nodejs and gives it the code for execution).
- therubyracer. Eats memory. It flows. The average execution speed of the component is ~ 10-20ms, but sometimes for every 10,000th request), it is podvison up to 100-200 ms.
- nodes are a safe way to execute JS code, BUT, for each component execution (there may be several of them on the page) ruby starts the nodejs process (that is, loads a binary file), feeds the source file and retrieves the results from STDOUT. The average execution speed of the component is 50-80ms, of which most of it goes to loading nodejs into memory and starting it.
We settled on therubyracer. At the moment, it renders 2-3 thousand components per minute. More than a year the flight is excellent. react-rails remained in the project and performs only the functions of a pre-tender.
Source: https://habr.com/ru/post/271489/
All Articles