Кто в теме, подскажите! В Kotlin есть очень удобная вещь, называемая «безопасные вызовы», позволяющая не писать проверку на null для цепочки вызовов, а просто использовать конструкцию вида: «bob?.department?.head?.name». Если одно из свойств имеет значение null, то вся цепочка вернет null. Планируется ли добавить подобный функционал в Python?
Так как автор не стал писать про Python в виду недостаточности знаний, немного напишу про этот язык и используемые фреймворки, может для кого-нибудь будет полезным. Тем, кто по какой-либо причине еще его не знает, а возможно даже обходит его стороной, хочется посоветовать, все-таки, присмотреться к этому языку получше. Я сам очень долго не хотел его изучать, и причина была не как у многих: «фу, да там все через отступы», а в том, что приводя плюсы питона (да простят меня люди говорящие «пайтон») обычно называют лаконичность языка. Часто приводят фразу в духе: «что на си занимает 100 строчек кода, в притоне это займет 10». Вот эта «простота» отпугивала, особенно после C++ и любимого С#. Казалось, что язык больше для «домохозяек» и людей не умеющих программировать на нормальных языках с нормальной типизацией, да и вообще язык только для скриптов. Я никогда так не ошибался! :) Язык очень мощный, невероятно удобный, который можно применять во многих областях. Я не знаю ни одного человека, перешедшего с PHP на питон, и который после этого опять хотел бы вернуться к PHP. Это я все к чему веду: питон отличный язык для того чтобы создавать на нем бэкэнд. Ну а теперь непосредственно про фреймворки… Для начала надо определиться: какой сервер нам нужен блокирующий или неблокирующий. У каждого из них есть плюсы и минусы. Неблокирующий сервер чаще всего используют для веб-сокетов, но на нем можно писать и обычные сайты, способные одновременно обрабатывать большое количество подключений. Но при работе с такими серверами надо помнить, что все подключения крутятся в одном «общем цикле» и блокировка этого «цикла» приведет к полной блокировки всех подключений, в связи с этим все используемые библиотеки должны быть не блокирующими. Среди неблокирующих фреймворков на сегодняшний день я бы советовал использовать aiohttp, есть и другие достаточно популярные такие как Tornado, но все они уступают aiohttp. Что же касается блокирующего фреймворка, то тут выделяется Django. Он подходит для людей, которые любят чтобы все было в одном флаконе и желательно сразу. Django уже «из коробки» включает в себя и шаблонизатор, и ORM, и многие другие удобные библиотеки. Но если Вы, как и, я любите выбирать библиотеки для каждой задачи свою, то тогда советую использовать Flask, а все остальные библиотеки уже настраивать под себя. Шаблонизатор чаще всего используют Jinja2, это достаточно удобный и распространённый шаблонизатор, с которым если и возникнут вопросы, то ответ можно будет нагуглить очень быстро. Что касается ORM, то в мире питона правит sqlalchemy. Это как пишет создатель peewee (конкурента sqlalchemy): «SQLAlchemy is the gold standard for ORM in the Python world» — и я с ним полностью согласен. Это универсальный и мощный инструмент. Но за все надо платить, в данном случае приходится «платить» сложностью данного фреймворка. Хотя, начать с ним работать можно очень быстро, а вникать в сложности уже в процессе. Есть очень много и других полезных библиотек, полезных при работе с веб, таких как wtforms, beautifulsoup, Pillow и т.д, но тут все уже зависит от конкретного проекта и задач, которые стоят перед разработчиком. Что-то слишком много букв получилось, но, надеюсь, для кого-то будет полезна данная информация.
Хорошая статья, но в ней есть очень большая «ложка дёгтя», а именно фраза про то, что роутинг и шаблонизация на бэкенде это извращения. Я не знаю Ruby, может с ним действительно что-то не так (в чем я сомневаюсь), но очень хорошо знаю Python и активно использую в своих проектах шаблонизатор Jinja2. И, исходя из своего опыта, могу выделить три способа формирования HTML-кода страницы, применяемых в современной веб-разработке:
Страница формируется с помощью шаблонизатора на сервере и уже готовый HTML-код отдается клиенту. У такого способа есть ряд преимуществ: клиенту не надо тратить ресурсы, на составление итогового кода самому; данный код может быть на сервере кэширован (частично или полностью) например, с помощью Redis; отдаваемая страница лучше индексируется поисковыми системами (но тут зависит от поисковой системы, по слухам, кто-то уже и JS-умеет обрабатывать).
Страница формируется уже клиентом, используя фреймворк (например, Vue), а с сервера запрашиваются только данные через API (REST, JSON-RPC и т.д.). У данного подхода есть свои плюсы, например, уменьшение трафика при обмене данными с сервером.
Третий способ это комбинирование первых двух, когда части HTML формируются на сервере и могут передаваться уже в процессе клиенту, либо когда первичная страница формируется на сервере, но итоговая «сборка» происходит на клиенте с помощью фреймворка.
Каждый способ имеет как свои плюсы, так и минусы, и выбирать надо исходя из поставленной задачи, а не потому что «так модно» или «так все делают».
Сейчас пилю проект где серверная часть на Python (flask, asyncio, sqlalchemy, jinja2), база на PostgreSQL, для кеширования и как брокер сообщений Redis, клиентская браузерная часть html5, CSS3, JavaScript (vue), клиентская мобильная часть Kotlin (rxjava, retrofit), используется паттерн MVVM. Все это взаимодействует через API (json-rpc) и WebSocket, периодически данные выгружаются из 1С (используя HTTP-сервисы 1с). Все это располагается на Linux VDS сервере (Nginx). Кроме этого всего, за годы программирования было изучено огромное количество других языков таких как C#, C++, PHP и т.д. НО! Как только я начитаю читать такие статьи, я понимаю, что меня не взяли бы даже на позицию джуниора. Хорошо грузчикам: не пьет – принят :)
Так поэтому я и написал, что полученный протокол не является чистым JSON-RPC и по этой причине в теле не используется «jsonrpc:2.0». Инструмент надо выбирать из задачи, а не наоборот. В моем случае отсутствует необходимость обращения сторонних серверов к моим API, нет необходимости 100% соответствовать стандарту. Зато этот подход позволяет мне разрабатывать более удобный интерфейс клиент-серверного взаимодействия.
Аргументация в данном случае простая и ее уже писали выше: «Потому что как транспорт — он свою задачу выполнил корректно, поэтому и 200». Если мы пытаемся отправить запрос по адресу «site.com/api/v1», а такой адрес отсутствует, то тогда возвращаем 404, или нет доступа – 403, возможно сервер упал в момент обработки и не смог сформировать ответ – 500. Но если сервер получил запрос и, исходя из бизнес-логики, решил что он ошибочный (например: объект не найден), то в таком случае я считаю правильно ответить кодом 200, а вот уже в JSON-ответе в поле «error» указать код и описание ошибки.
В своих проектах я решаю минусы JSON-RPC очень простым способом, для запросов, передающихся через HTTP, просто выношу поле method в URL, строка запроса при этом выглядит как «/api/posts.add», где «posts.add» значение method, а параметры передаю уже в теле через params. Но я не использую batch-операции т.к. в зависимости от метода, балансировщиком выбирается сервер обработки и мешанина методов в одном пакете в этом случае только мешает. Также не использую в теле «jsonrpc:2.0» из-за того что полученный протокол не является чистым JSON-RPC. В остальном же стараюсь придерживаться стандарта.
Каждый способ имеет как свои плюсы, так и минусы, и выбирать надо исходя из поставленной задачи, а не потому что «так модно» или «так все делают».
В данном случае небольшое отклонение от стандарта дает немало ценных преимуществ, компенсирующих вышеупомянутые проблемы.