Очень часто можно услышать про REST vs SOAP. Большое количество материалов про веб-сервисы ограничиваются SOAP и REST.

Мне не нравится, что многие упираются только в эти 2 подхода, будто других способов связи с сервисом нет. Вы можете с лёгкостью найти и другие решения, и оценить их применимость. Главное нужно критически анализировать разные подходы, а не просто читать обзоры. Нередко авторы статей из интернета не имеют нужных знаний.

REST - используем http протокол с некоторым набором правил (http://www.restapitutorial.com/)

SOAP - протокол (application layer модели OSI) формат сообщений строго описан, используется xml

Что если мы хотим передавать в бинарном виде?

RPC - Remote procedure call, здесь можете встретить информацию про RMI и CORBA, это мёртвые технологии, смотрите подходы новее.

Посмотрите на protobuf от гугла https://developers.google.com/protocol-buffers/ или https://thrift.apache.org/ . Это такие универсальные бинарные форматы сериализации.

gRPC (https://grpc.io/) - это такой RPC фреймворк от гугла, он использует protobuf. Интересное решение, если нужно организовать коммуникацию с минимальными накладными расходами.

MQ - message brokers, этот подход основан на введением в систему специального middle ware. Логика простая, одно приложение что-то добавляет в очередь, другое (или другие) читают эти сообщения и обрабатывают. Сообщения в данном случае могут быть просто объекты, или какие-то команды (тогда получится своего рода rpc). Посмотрите список доступных брокеров http://queues.io/ . Наиболее популярные ActiveMQ, Apache Kafka, RabbitMQ. У каждого свои плюсы и минусы, и нужно выбирать под проект.

Этот пост никак нельзя назвать обзором, просто мотивация смотреть на разные подходы при организации взаимодействия между сервисами. Например можно и сокеты использовать, и найдутся примеры где это будет иметь смысл:) Или использовать разные БД с подписками. Могу сделать полноценный пост по данной теме, пишите в ЛС.

#web #services #thinking #dev #programming

Ссылка из архива полезных ссылок https://12factor.net/

Несколько лет назад heroku составили 12 правил/принципов разработки веб приложений. Правила обрели популярность и считаются хорошими практиками. Думаю в современных реалиях каждый программист занимающейся бекенд-разработкой должен ознакомиться с ними. Список переведён на множество языков, прочитайте и ваши приложения станут лучше, а волосы шелковистее.

#developing #web #backend

Предпочитаю docker-подход к деплойменту приложений. Однажды натолкнулся на интересный баг-особенность на centos.

Описание ситуации:
У вас есть несколько контейнеров:
- backend с REST API
- frontend приложение, которое использует это API,

Оба приложения, естественно имеют свой контейнер. Frontend ходит к API через внешний адрес (естественно через прокси, но это не имеет значения здесь). С дефолтными настройками вы можете столкнуться с проблемой, что ваш контейнер не может получить доступ к API, хотя:
1. Они на одной машине
2. API доступно для всех публично, и с любой другой машины API работает.

Причина в особой конфигурации firewall на centos, что легко исправляется добавлением сети докера в исключения, но не забывайте, что если сеть докера не задана, то при каждом запуске контейнеров docker-сеть может отличаться, поэтому советую задать её явно.

Подробнее здесь https://forums.docker.com/t/no-route-to-host-network-request-from-container-to-host-ip-port-published-from-other-container/39063

Простой фикс для копипаста (не копируйте, если не понимаете, что происходит):

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.19.0.0/16 accept' && firewall-cmd --reload

и конфигурация сети в docker-compose

networks:
  my-net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.19.0.0/16

#docker #web #rest #linux #issues

Следующая информация может быть полезна, если вы хотите запустить jupyter notebook на сервере, сделать сервис публично доступным и сделать это правильно, https и запрятать за каким-нибудь прокси.

Всё кажется предельно просто, запускаем jupyter (лучше в контейнере конечно), настраиваем https на вашем любимом сервере, например apache и настраиваете прокси на ваш jupyter. И всё действительно просто, но не совсем. Jupyter использует прекрасную технологию WebSocket для того, чтобы всё было максимально интерактивно и без WebSocket никак, если вы не пропишите правильно инструкции для прокси, вебсокеты у вас отвалятся, jupyter не будет работать и вообще всё плохо, вы резко перестаёте любить новые технологии.

Но всё не так печально, есть большой стрим обсуждений на github, и там у вас есть всё что надо.

https://github.com/jupyterhub/jupyterhub/issues/219

ProxyPreserveHost On
ProxyRequests off

ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/

ProxyPass /api/kernels/ ws://127.0.0.1:8888/api/kernels/
ProxyPassReverse /api/kernels/ https://127.0.0.1:8888/api/kernels/

<Location ~ "/(user/[^/]*)/(api/kernels/[^/]+/channels|terminals/websocket)/?">
    ProxyPass ws://localhost:8000
    ProxyPassReverse ws://localhost:8000
</Location>

Возможно, нужно понадобится добавить ещё эти строчки, перед <Location ... :

Header edit Origin {external address} localhost:8000
RequestHeader edit Origin {external address} localhost:8000

Header edit Referer {external address} localhost:8000
RequestHeader edit Referer {external address} localhost:8000

Ещё нужно сконфигурировать сам jupyter, см. настройки в документации. В файле jupyter_notebook_config.json можно добавить следующее.

{
  "NotebookApp": {
    "ip": "*",
    "allow_origin": "*",
    "open_browser": false,
    "password": "sha1:yourpass hash",
    "trust_xheaders": true
}
}

#jupyter #deployment #web #issues