Special things learned from Readyforzero

Summary: Web application development tends to run all user logic and interaction code on the client, exposing the server to rest or RPC interfaces. The compiler is targeted at JS as a platform, and the second edition of ECMAScript is designed to take this into account. Client frameworks such as

Web application development tends to run all user logic and interaction code on the client, exposing the server to rest or RPC interfaces. The compiler is targeted at JS as a platform, and the second edition of ECMAScript is designed to take this into account. Client frameworks such as backbone, Ember, and require encourage the creation of feature-rich applications that have not only rich code but also many interactions between components, components, and data.

This is really good, and it may also produce some excellent user experience, but there is no doubt that it is difficult to develop Web applications and Web pages.

The root cause is to serve your code and data on the Internet, run on some random browsers, in JavaScript, a language you need to be particularly careful about, a platform that is completely devoid of code deployment. And it won't get better soon. I think if Star Trek is real life, then Luc Picard captain every once in a while can't fight because he still is the Clindamycin dashboard loaded.

I want to highlight three relatively common mistakes and easy solutions, and talk about some of the special things we've learned from Readyforzero.

Split Cache cleanup Header information

It is certainly reasonable that you might use a CDN to cache static resources. If you request a server that is not cached (such as using "Custom-origin" on the AWS side to point the file to a real Web site), you need to be careful. You may be able to add a cache-purged string (header) to the filename after you deploy the new version of the file to that end, so that your filename looks like this:

Http://example.com/js/main__V0123456789abcdef__.js

This is easy to do, you can choose any hash algorithm to generate a piece of fingerprint information as the string, so that it will change as the contents of the file changes. When a new URL is referenced, it cannot be cached so that a new version of the server can be obtained. The mistake happened here. There are a lot of suggestions on the web that the "cache cleanup" header information should be stripped, instead of having your server provide a new version of the file directly. If you have multiple server clusters this may cause different files on your site (e.g.: HTML, JS version inconsistency (such as JS has been updated but HTML (request from another server) is still old), not only that, but also more serious is that it can easily lead to a CDN cache the wrong version. This error occurs:

• Initial phase, all servers are HTML1 and JS1.

• Server A reboots and provides HTML2 and JS2.

• A client requests main__v2__.js to the CDN, this time the file is new so there is no caching on the CDN.

· The CDN passed the request to the custom origin you set up, and it happened that the request was sent to Server B.

• Server B stripped the cache purge string and returned the old version.

· The CDN used the old version of the file as a new cache.

This is a simple matter to consider, but blindly heeding the advice on the web can lead to errors. What's worse is that in you it seems like everything is good you don't know what happened, but users in other areas use different CDN and are likely to cache the wrong version. The solution is not to split the cache purge string and store the static resources where each version is supported correctly.

2. Deal with the huge JS bomb

Everyone knows that we need to compress our JavaScript files and connect them together. But it is unwise to do so blindly. If the attached file is large, the more efficient approach is parallelization. In addition, if you need to frequently modify a part of a file, you may cause many places to fail, and most of the files have not been modified.

If you separate frequently modified parts, you can solve both sides of the problem. I recommend using Require.js-it enables true dependency management on your JavaScript, and the first time you use it, the settings are simple (painful to add later), and can help you understand and manage dependencies, including advanced options such as asynchronous loading.

Note: Require.js will be waiting for a while to discard the load resources, this can be implemented by specifying the Waitseconds option, the default value of this option seems to be 7 seconds, it depends on where your users (for example: Mobile phone), can be a very short time.

3. No Summary error events

You can't just let your JavaScript go online and not care about its operation. You cannot test the state combinations of each browser and each user. In addition, different loading times can lead to weird states. So it's important to establish some kind of feedback mechanism to determine whether your users are encountering errors. This is simple, you just need to specify a global error handler, collect errors, and send the server. Here is an example:

The tricky part is that there are a lot of errors that are not 0, because the user may have a variety of weird plug-ins or other. So you need to keep track of what the stable state is and whether there are any deviations.

Readyforzero, we capture the onerror events at the top level and send them to the server, then generate a daily paper summarizing how many users have made the error, and where these errors occurred. We find that many times the error message is not enough, so we also need to return the last few events from our event system. By analyzing the backbone or jquery events that the user has recently triggered, it is helpful to get contextual information when the user triggers the error.

An improvement that is readily available

The depressing point is that the following points are not something we have to worry about. Companies should focus on products, quickly and with high quality to get them out. But keep in mind that if these praise improvements are implemented, you will be able to focus more on the big moves.

It takes a lot of time for people to get tangled up in trifles, but it's great to grow up just to get your application working.

1, does your client code have a memory leak? Are you sure? How do you know?

2, in readyforzero[Note 1] We have a lot of smart people who are committed to promoting this art.

[Note 1] Readyforzero: A company funded by Y Combinator, the company's goal is to help consumers get out of credit card debt through a network platform.