mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-28 03:25:55 +08:00
8-9
This commit is contained in:
@ -1,40 +1,27 @@
|
||||
# Title here
|
||||
# Sure user experience with APM products
|
||||
|
||||
<br/><br/>
|
||||
|
||||
|
||||
### One Paragraph Explainer
|
||||
|
||||
Text
|
||||
APM, application performance monitoring refers to a familiy of products that aims to monitor application performance from end to end, also from the customer persepective. While traditional monitoring solutions focuses on Exceptions and standlone technical metrics (e.g. error tracking, slow server endpoints, etc), in real world our app might create disappointed users without any code exceptions, for example if some middleware service performed real slow. APM products measure the user experience from end to end, for example, given a system that encompass frontend UI and multiple distirbuted services – some APM products can tell how fast a transaction that spans multiple tiers last. It can tell whether the user experience is solid and point to the problem. This attractive offering comes with a relativelly high price tag hence it’s recommended for large-scale and complex products that require to go beyond straightforwd monitoring.
|
||||
|
||||
<br/><br/>
|
||||
|
||||
|
||||
### Code Example – explanation
|
||||
### APM example – a commercial product that visualize cross-service app performance
|
||||
|
||||
```javascript
|
||||
code here
|
||||
```
|
||||

|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Code Example – another
|
||||
### APM example – a commercial product that emphasize the user experience score
|
||||
|
||||
```javascript
|
||||
code here
|
||||
```
|
||||

|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Blog Quote: "Title"
|
||||
From the blog pouchdb.com, ranked 11 for the keywords “Node Promises”
|
||||
|
||||
> …text here
|
||||
### APM example – a commercial product that highlights slow code paths
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Image title
|
||||

|
||||
|
||||
|
||||
<br/><br/>
|
||||

|
||||
|
||||
@ -1,40 +1,17 @@
|
||||
# Title here
|
||||
# Make your code production-ready
|
||||
|
||||
<br/><br/>
|
||||
|
||||
|
||||
### One Paragraph Explainer
|
||||
|
||||
Text
|
||||
Following is a list of development tips that greatly affect the production maintenance and stability:
|
||||
|
||||
<br/><br/>
|
||||
|
||||
|
||||
### Code Example – explanation
|
||||
|
||||
```javascript
|
||||
code here
|
||||
```
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Code Example – another
|
||||
|
||||
```javascript
|
||||
code here
|
||||
```
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Blog Quote: "Title"
|
||||
From the blog pouchdb.com, ranked 11 for the keywords “Node Promises”
|
||||
|
||||
> …text here
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Image title
|
||||

|
||||
|
||||
|
||||
<br/><br/>
|
||||
* The twelve-factor guide – Get familiar with the [Twelve factors](https://12factor.net/) guide
|
||||
* Be stateless – Save no data locally on a specific web server (see separate bullet – ‘Be Stateless’)
|
||||
* Cache – Utilize cache heavily, yet never fail because of cache mismatch
|
||||
* Test memory – gauge memory usage and leaks as part your development flow, tools such as ‘memwatch’ can greatly facilitate this task
|
||||
* Name functions – Minimize the usage of anonymous functions (i.e. inline callbabk) as a typical memory profiler will provide memory usage per method name
|
||||
* Use CI tools – Use CI tool to detect failures before sending to production. For example, use ESLint to detect reference errors and undefined variables. Use –trace-sync-io to identify code that uses synchronous APIs (instead of the async version)
|
||||
* Log wisely – Include in each log statement contextual information, hopefully in JSON format so log aggregators tools such as Elastic can search upon those properties (see separate bullet – ‘Increase visibility using smart logs’). Also, include transaction-id that identifies each request and allows to correlate lines that describe the same transaction (see separate bullet – ‘Include Transaction-ID’)
|
||||
* Error management – Error handling is the Achilles’ heel of Node.JS production sites – many Node processes are crashing because of minor errors while others hang on alive in a faulty state instead of crashing. Setting your error handling strategy is absolutely critical, read here my [error handling best practices](http://goldbergyoni.com/checklist-best-practices-of-node-js-error-handling/)
|
||||
|
||||
Reference in New Issue
Block a user