Comme geeks codage nous-mêmes, ce blog sera également en vedette des articles sur nos propres expériences de développement. La semaine dernière a été un moment charnière de notre développement: je décidai d'aller sans serveur. Même il ya une semaine, si je l'avais mis MonsterCoding.com en ligne, il aurait été servi par Node.js. I love effectivement Node.js, et il a fait du développement des applications riches moyen plus facile de l'internet. Ai-je accès à des tonnes de bibliothèques cool sur mon bureau que je peux utiliser dans Grunt ou via la ligne de commande pour automatiser choses, des choses nettoyer, traiter mes modèles et les fichiers, etc. SASS
Mais je ne suis pas un expert à Node.js. Et l'utiliser pour réellement servir notre site Web et l'application m'a fait vraiment nerveux. Node.js a l'habitude peur de terminer l'arrêt sur une petite erreur. Cela signifie que l'ensemble de votre site tombe en panne, pas seulement la page ou le processus incriminé. Comme nous nous préparons pour l'Heure du Code, l'idée de l'application servi par un backend que je bricolé avec des échantillons en ligne, et pourrait tomber en panne à tout moment, m'a donné beaucoup de pause Quelle douce idée. Depuis notre site Web et l'application sont Backbone.js, Dust.js et jquery.js au cœur d'une des choses, dégager le login et certaines des routes de Node.js était un jeu d'enfant. Maintenant, je peux utiliser un Lambda AWS pour notre connexion sociale, ainsi que la sauvegarde des données de l'utilisateur vers le Cloud.
Le site est desservi via d'Amazon CloudFront, qui a quelques 15 endroits où
| Accueil | Sur |