​​Ищу мидл-разработчика · $20-30/час до налогов · фриланс

Привет!

Я ищу к себе в проект крепкого мидл-JavaScript-разработчика.

Компания, с которой я работаю, делает инфраструктуру для контент-маркетинга. С помощью этой инфраструктуры бизнесы пишут себе тексты и зарабатывают больше. Сейчас мы делаем новый продукт, который станет частью инфрастуктуры, и нам нужны руки :–)

Разработка началась пару месяцев назад, скоро будет закрытая бета. Стек: React (Next.js) · Node.js · AWS.

Это фриланс, поэтому круто, если вы можете работать напрямую с клиентом. Если вы в Беларуси, могу попробовать трудоустроить к себе.

Что у нас
— $20-30/час до налогов
— Удалёнка и любой график (работайте хоть ночью)
— Клёвый клиент, куча самостоятельности, можно самим принимать мелкие продуктовые решения

Что нужно
— Уметь работать с React и Node.js
— Уметь внятно переписываться по-английски (мы общаемся только на нём)
— Работать 4-6 часов в день

Клёво, если вы ещё
— Умеете отличать хорошие интерфейсы от плохих
— Контрибьютили в или работали с Ghost (http://ghost.org/)
— Работали с Amazon Web Services или Google Cloud Platform

Если хотите присоединиться, напишите мне письмо. В письме расскажите, почему вы подходите для этой работы → mail@iamakulov.com

Действительно огонь:

Жизнь крутанула финт и случайно закинула меня на Хабрахабр, а там я нашёл потрясную статью для разработчиков про 7 небольших приёмов которые могут привести дизайн в порядок, если вы не дизайнер.

→ https://medium.com/refactoring-ui/40c736799886

Шерьте друзьям!

А мы наконец-то продолжаем. Теперь про инфраструктуру.

Напоминаю, что это серия постов про то, что делать, если вы проснулись однажды утром после беспокойного сна и обнаружили себя фулстеком. Начало тут: https://t.me/iamakulov_channel/258

Я написал приложение. Как мне его выкатить в продакшен?
Чтобы приложение работало в продакшене, вам нужно запустить его в отдельном выделенном месте. Для этого есть куча сервисов; я слышал про такие:
— Heroku
— Now.sh
— DigitalOcean
— Amazon Web Services (AWS)
— Google Cloud
— Microsoft Azure

Первые три — простые, понятные и красивые. Например, Heroku просто подключается к git-репозиторию с приложением и обновляет его каждый раз, когда вы пушаете код. Всей инфраструктурой при этом управляют они сами.

Вторые три — огромные пакеты с кучей сервисов. Например, меню в AWS выглядит вот так:

(не забудьте посмотреть на скроллбар)

Плюс этого — всё, что вы можете придумать, в AWS уже есть (и интегрировано друг с другом).
— Нужно отправлять почту? Simple Email Service
— Надо покупать домены? Route 53
— Хотите положить файлы на CDN? CloudFront

Я считаю, что для полноценных приложений лучше брать крупный сервис вроде AWS. Heroku, как мне кажется, больше подходит для пет-проектов и мелкого продакшена, который сильно не вырастет. Но вы лучше спросите у знакомого девопса, чтобы наверняка.

Дальше буду рассказывать про AWS.

Окей, я зарегистрировался на AWS. Как сервисы мне могут понадобиться?
— Для запуска самого приложения → EC2 или ECS. EC2 — это обычная виртуальная машина с полным доступом по SSH. ECS помогает с докер-контейнерами, но с ним я не работал.

— Для базы данных → RDS. RDS — это сервис для хостинга MySQL, PostgreSQL или MS SQL; вы создаёте в нём базу данных и получаете реквизиты, по которым подключаться.

Для MongoDB готовых решений нет ¯\_(ツ)_/¯. Впрочем, есть AWS DynamoDB — NoSQL-база данных от Амазона.

— Для файлов → EBS, EFS или S3.
EBS — это обычное перманентное файловое хранилище;
EFS — такое же файловое хранилище, но дороже и может подключаться к нескольким машинам одновременно;
S3 — сервис, чтобы хранить статические файлы и отдавать их по публичному урлу.

— Для лоад-балансинга → Elastic Load Balancing

— Для бекапов → Glacier

Не факт, что вам понадобятся все эти сервисы — тот же лоад-балансинг можно организовать, например, обычным Nginx-ом. Смотрите, что вам проще, и считайте стоимость.

А как мне корректно поднять приложение на EC2?
1. Создайте EC2. Мастер создания большой, но стандартные настройки ок — позже разберётесь. В качестве ОС выбирайте Ubuntu — по ней больше всего статей и туториалов.

2. Подключитесь по SSH (кнопка Connect в списке EC2-машин) и установите нужные зависимости (Git, Node.js и всё такое).

3. Разберитесь, как сделать, чтобы код приложения попадал на машину. Если приложение хранится в GitHub-е, то самый простой способ — это сгенерировать deployment-ключ и клонировать приложение через Git.

4. Установите pm2. pm2 — это инструмент, который мониторит приложение и перезапускает его, если оно умирает. Настройте его, как в туториале DigitalOcean.

5. Установите и настройте Nginx, как в туториале. Nginx — это сервер, который умеет проксировать запросы, сжимать ответы, кешировать данные и ещё кучу всего. Его обычно ставят перед Node.js-приложением — с ним удобнее.

6. Пойдите в настройки EC2 и разрешите входящий HTTP-трафик с порта 80 (это порт для HTTP-соединений)

Всё, осталось только запустить.

Хм, так я же могу поднять на этом же EC2-сервере и базу данных. Зачем мне RDS?
Так действительно можно сделать, но я не советую:
— Это менее безопасно. С RDS база данных находится на другой машине, и если кто-то получит доступ к продакшен-серверу, то доступ к базе у него всё равно будет ограничен.

— Это менее надёжно. В RDS Амазон сам бэкапит данные и заботится о доступности, а с локальной базой данных вам придётся настраивать это вручную.

Окей, у меня всё заработало. А что теперь сделать, чтобы всё было безопасно?
Помимо стандартных мер (хешируйте пароли! не верьте никому!), стоит ограничить доступ сервисов друг к другу. Тогда злоумышленник, взломав ваш стейджинг-сервер, не сможет скопировать себе продакшен-базу. Вот что нужно сделать для этого:

➡️ Настройте всем сервисам роли (IAM roles)
Роли ограничивают доступ одного сервиса к другому через API. Работает это так: вы создаёте роль → выбираете в ней минимально нужные права (например, запись в S3) → в настройках сервера указываете эту роль → теперь сервер может использовать API только для записи в S3.

Роли работают только тогда, когда вы делаете запросы через API. Если вы обращаетесь к базе данных или отправляете почту через SMTP, роли не помогут.

➡️ Настройте всем сервисам секьюрити-группы (security groups)
А вот секьюрити-группы как раз ограничивают сетевые запросы, как файрволл. Их полезно использовать вот так:

— Разрешить доступ к базе данных только с продакшен-сервера. Вы помещаете продакшен-сервер в секьюрити-группу SG1 → помещаете базу данных в секьюрити-группу SG2 → и в настройках SG2 разрешаете входящий трафик только из SG1. (Всё это делается в настройках сервера и БД.)

— Разрешить доступ к продакшен-серверам только по SSH и HTTP(S). Вы идёте в настройки SG1 и во вкладке Inbound traffic разрешаете только эти три вида траффика.

➡️ Отключите публичный доступ к базе данных
В настройках базы данных в RDS есть флажок Publicly Accessible — снимите его, чтобы отключить доступ из внешнего интернета. База данных и так должна быть защищена секьюрити-группой, но если в ней вдруг возникнет уязвимость, этот флажок может спасти ваши данные.

(Есть что добавить насчёт безопасности? Расскажите → @iamakulov_channel_chat)

А какие минусы AWS?
То, что я заметил:
— Куча сервисов — это реально сложно. Я первый месяц сильно плавал, пока не разобрался в базовых концептах. Сейчас я чувствую себя увереннее, но всё равно поработал мало с чем.

— Неочевидные цены. Стоимость EC2-сервера зависит от мощности сервера, региона, времени работы и количества трафика — в итоге приходится искать нужные цены в таблицах, умножать их и складывать то, что получается. Так со всеми сервисами, которые я видел.

(Знаете ещё минусы? Добавьте → @iamakulov_channel_chat)

Не всё! У Амазона есть AWS Free Tier: https://aws.amazon.com/free/ — грант на 12 месяцев для использования каких-то ресурсов.

Для цен AWS
https://calculator.s3.amazonaws.com/index.html

👋 По Амазону.

1. Еще один недостаток размещения БД на том же EC2-сервере, где код:

— Это менее масштабируемо. RDS позволяет в случае нагрузки быстренько поднять еще один/два/десять EC2-серверов (рост вширь), и проблем с БД не будет. На обычных VPS-ках (Digital Ocean тот же) это достигается размещением БД на отдельном VPS, либо в облаке, например, на compose.com (кстати, там есть и Монга).

2. Digital Ocean потихоньку расширяют инфраструктуру, сохраняя при этом простоту использования. Сейчас у них есть отдельные балансировщики нагрузки и два сервиса под хранение данных. Не AWS, конечно, но для стартапов с возможностью роста — вполне.

​​Кстати, я немного раньше постил вакансию. Закрыть её мне помогли ребята из канала @RemoteIT — их репост привёл нужного человека. Взамен они попросили упомянуть канал у себя.

@RemoteIT — это канал с вакансиями удалённой работы. На канале выходит две-три вакансии в день; есть ещё соседний @CVFlow, где можно разместить резюме.

Мне чертовски понравилось, что все посты в RemoteIT оформлены в одном формате. Я видел пару других каналов про работу, и там были форварды текста от компаний — через это приходилось продираться.

Подписывайтесь, короче → @RemoteIT

​​Хинт: избегайте джаваскриптовых геттеров и сеттеров. Они не дают никаких преимуществ, но усложняют понимание кода.

Как только вы начнёте использовать геттеры, вы больше никогда не сможете ответить сходу, что такое this.readableColorName — обычное свойство или какой-то геттер, который зависит от окружения и может сломаться.

В личке добавили, что геттеры и сеттеры не всегда плохи — например, их удобно использовать для computed props во всяких фреймворках.

Всё так. Короче, относитесь к этому совету, как ко всему, что читаете. Если вы точно знаете, когда это можно нарушить — нарушайте. Если не уверены — наверное, лучше не стоит

​​Если вы используете библиотеку async и импортируете её одним импортом:

import async from 'async'

в бандл попадают все методы библиотеки (даже если вам нужна только пара их них).

Написал, как выбросить неиспользуемые методы с Babel и babel-plugin-lodash: https://github.com/GoogleChromeLabs/webpack-libs-optimizations#async