What to evaluate and consider before adding usage of new third-party crates.
These are not exact requirements but questions to investigate and discuss to help reason around the health, safety, maintainability, and more around crates.
This can also be read as an opinionated guide for crate authors of what our (Embark's) guidelines and recommendations are, though should not be taken too literally.
Legend: 🔒 Must have, ⭐️ Should have, 👍 Nice to have, ℹ️ Info
| # UPDATED 17 February 2019 | |
| # Redirect all HTTP traffic to HTTPS | |
| server { | |
| listen 80; | |
| listen [::]:80; | |
| server_name www.domain.com domain.com; | |
| return 301 https://$host$request_uri; | |
| } | |
| # SSL configuration |
| server { | |
| listen 80; | |
| server_name localhost; | |
| root /Users/YOUR_USERNAME/Sites; | |
| access_log /Library/Logs/default.access.log main; | |
| location / { | |
| include /usr/local/etc/nginx/conf.d/php-fpm; | |
| } |
| /** | |
| * Fancy ID generator that creates 20-character string identifiers with the following properties: | |
| * | |
| * 1. They're based on timestamp so that they sort *after* any existing ids. | |
| * 2. They contain 72-bits of random data after the timestamp so that IDs won't collide with other clients' IDs. | |
| * 3. They sort *lexicographically* (so the timestamp is converted to characters that will sort properly). | |
| * 4. They're monotonically increasing. Even if you generate more than one in the same timestamp, the | |
| * latter ones will sort after the former ones. We do this by using the previous random bits | |
| * but "incrementing" them by 1 (only in the case of a timestamp collision). | |
| */ |
