Пардон, поправка: тривиальные типы (типа string, int и т. п.) не могут быть nullable. Вложенные сообщения - могут. Для этого в well-known types как раз и сделаны типы наподобие Int64Value. Скорее всего, авторы в этом плане ориентировались на Go, где такая же логика и аналогичные типы для работы с sql.
Просто это сделано не слишком логично, учитывая наличие ключевых слов required и optional - благо от этого решили отказаться в третьей версии protobuf.
Извините, но по части аргументации местами написана откровенная ахинея. Да и код вам бы подправить, а то какая-то кривая копипаста, без стилевого оформления и с левыми "1 reference".
Реальный плюс GRPC всего один: использование одного HTTP/2 соединения для отправки множества запросов. Это ускоряет отправку запросов и получение ответов. Для REST это также никто не запрещает делать, но в дикой природе гораздо чаще встречается HTTP/1, который гораздо легче разбирать.
protobuf - формат неплохой, но не самый лучший. Например, по задумке авторов поля не могут быть nullable, что не всегда удобно. Существуют только примитивные типы, которые нужно вручную преобразовывать в нужный (та же дата/время, например). Да, в JSON типов еще меньше, но при этом в большинстве REST-фреймворков существует встроенная сериализация/десериализация для многих стандартных типов. В protobuf - нифига, бери строковое значение из поля и парси вручную.
Генерация кода... Да, можно сгенерировать код клиентской библиотеки и серверный бойлерплейт для многих языков. Но этот код зачастую сложен для понимания и анализа, в связи с чем IDE не всегда может адекватно сформировать подсказки по методам и полям. И чем это отличается от генерации кода для OpenAPI? Это притом, что OpenAPI часто генерируется автоматически на основе аннотаций в коде, и в нем можно указать гораздо больше различных данных: описания методов и полей, авторизация для методов, валидация передаваемых данных и т. п.
Обработка ошибок в GRPC тоже выглядит странновато. Если метод кидает исключение - не факт, что GRPC его отловит и вернет ошибку. Вместо этого нужно перехватывать исключения вручную и возвращать ошибки специальным способом - причем разным для каждого языка (то есть нельзя писать серверное приложение на Python, а потом с этим же опытом прийти в Go, GRPC API будет чувствительно различаться).
Все остальное - трассировка, health check, балансировка нагрузки, аутентификация и т. п. - либо не зависит от выбора "GRPC или REST", либо банально проще и удобнее в REST. Например, во многих REST-фреймворках есть интеграция с Prometheus, а для health check не нужно заводить отдельный класс. Балансировка нагрузки и аутентификация относятся скорее к API gateway (nginx/krakend/kong/tyc etc.) и к service mesh (istio etc.), а авторизация не доставляет проблем ни там, ни там.
Вполне возможно, что я где-то не прав, сужу чисто по личному опыту.
Кстати, ещё одна из проблем - это контент 18+. В том же Second Life он занимает довольно значительную часть. Но в различных VR-метавселенных, типа VRChat, Sansar, Altspace и т. п., 18+ контент либо запрещен полностью, либо разрешен только в приватных зонах.
Жалко, что тот же Second Life, со всем его разнообразием контента, нельзя нормально адаптировать к VR, чисто из-за жестко фиксированных анимаций. Да развивается он откровенно черепашьими шагами, обладая при этом шлейфом застарелых багов и не проводя ни недели без падений.
Как вариант, можно написать скрипт или приложение, которое будет реагировать на свое имя файла. Для одного имени файла - какой-то безобидный функционал, для другого - дополнительно нечто вредоносное. Все равно практически никто не лазит с дизассемблером по файлам после их распаковки.
Почему бы в данном случае не использовать на стороне базы данных тип даты-времени с сохранением часового пояса (`timestamp with time zone` / timestamptz в Postgres)?
Получится красиво: и сохранение локального времени независимо от локации, и возможность отображать его в произвольном часовом поясе, и правильная сортировка по данному полю.
Правда, не уверен, сохраняет ли тип DateTime в C# часовой пояс.
Как вариант, можно парсить конфиг и проверять, нет ли чересчур больших значений для каких-нибудь параметров, которые могут уронить сервер. Есть пара библиотек для Go: [1], [2].
Сам когда-то давно писал парсер конфигов, только на сях. Написано криво-косо, но работает до сих пор :)
Знаете, чем мне не нравится передача ошибок (как в Go и Rust) и нравятся исключения?
Тем, что при передаче ошибок приложение становится гораздо сложнее отлаживать. Теряется информация, откуда именно пришла ошибка. При использовании исключений можно вывести stack trace до места, где возникло это самое исключение.
Тем, что невозможно заранее узнать, какие ошибки может возвращать функция. В принципе, с исключениями тоже не всегда можно узнать, какая функция какое исключение может кинуть, но обычно для этого есть если не языковые конструкции (как throws в Java), то хотя бы комментарии (как в PHP).
Использование panic в чем-то похоже на исключение, но не позволяет указать его тип — просто некая глобальная ошибка, которую можно где-то отловить, и все, что про нее известно, это ее текстовое описание.
Поможет это тем, что приложение не будет впустую ожидать, пока обработчик запроса получает данные из БД, а начнет обрабатывать в это время другой запрос.
Зачем брать асинхронный фреймворк, но при этом заставлять его работать синхронно? У SQLAlchemy недавно появился асинхронный режим работы, используйте его.
Цензура в общем виде — это контроль над информацией и ее распространением. Она бывает не только государственной. Мама запрещает ребенку говорить матерные слова — это тоже своего рода цензура.
Насчет всеми любимой статьи 29… Пролистайте чуть ниже, до статьи 55:
3. Права и свободы человека и гражданина могут быть ограничены федеральным законом только в той мере, в какой это необходимо в целях защиты основ конституционного строя, нравственности, здоровья, прав и законных интересов других лиц, обеспечения обороны страны и безопасности государства.
Чувствуете расплывчатость формулировки, благодаря которой можно абсолютно законно наплевать на любую из статей 19-54?
Окей, если серьезно, то и те, и другие занимаются цензурой, в соответствие с какими-то своими принципами. Цензура — это и есть нарушение принципов свободного распространения информации и беспрепятственного доступа к ней. И довольно забавно видеть, как волк с окровавленной мордой кричит, что он против нарушений принципов вегетарианства.
Ну и разница в том, что одни (YouTube) еще как-то пытаются подстроиться под других, а эти самые другие (РосКомНадзор) плюют на все и делают, что хотят — решают, кого считать врагами народа, и периодически осуществляют блокировки значительной части интернета (все помнят про блокировки AWS и Google Public DNS?)
Роскомнадзор в свою очередь потребовал от YouTube перестать нарушать ключевые принципы свободного распространения информации и беспрепятственного доступа к ней.
Пардон, поправка: тривиальные типы (типа string, int и т. п.) не могут быть nullable. Вложенные сообщения - могут. Для этого в well-known types как раз и сделаны типы наподобие Int64Value. Скорее всего, авторы в этом плане ориентировались на Go, где такая же логика и аналогичные типы для работы с sql.
Просто это сделано не слишком логично, учитывая наличие ключевых слов required и optional - благо от этого решили отказаться в третьей версии protobuf.
Извините, но по части аргументации местами написана откровенная ахинея. Да и код вам бы подправить, а то какая-то кривая копипаста, без стилевого оформления и с левыми "1 reference".
Реальный плюс GRPC всего один: использование одного HTTP/2 соединения для отправки множества запросов. Это ускоряет отправку запросов и получение ответов. Для REST это также никто не запрещает делать, но в дикой природе гораздо чаще встречается HTTP/1, который гораздо легче разбирать.
protobuf - формат неплохой, но не самый лучший. Например, по задумке авторов поля не могут быть nullable, что не всегда удобно. Существуют только примитивные типы, которые нужно вручную преобразовывать в нужный (та же дата/время, например). Да, в JSON типов еще меньше, но при этом в большинстве REST-фреймворков существует встроенная сериализация/десериализация для многих стандартных типов. В protobuf - нифига, бери строковое значение из поля и парси вручную.
Генерация кода... Да, можно сгенерировать код клиентской библиотеки и серверный бойлерплейт для многих языков. Но этот код зачастую сложен для понимания и анализа, в связи с чем IDE не всегда может адекватно сформировать подсказки по методам и полям. И чем это отличается от генерации кода для OpenAPI? Это притом, что OpenAPI часто генерируется автоматически на основе аннотаций в коде, и в нем можно указать гораздо больше различных данных: описания методов и полей, авторизация для методов, валидация передаваемых данных и т. п.
Обработка ошибок в GRPC тоже выглядит странновато. Если метод кидает исключение - не факт, что GRPC его отловит и вернет ошибку. Вместо этого нужно перехватывать исключения вручную и возвращать ошибки специальным способом - причем разным для каждого языка (то есть нельзя писать серверное приложение на Python, а потом с этим же опытом прийти в Go, GRPC API будет чувствительно различаться).
Все остальное - трассировка, health check, балансировка нагрузки, аутентификация и т. п. - либо не зависит от выбора "GRPC или REST", либо банально проще и удобнее в REST. Например, во многих REST-фреймворках есть интеграция с Prometheus, а для health check не нужно заводить отдельный класс. Балансировка нагрузки и аутентификация относятся скорее к API gateway (nginx/krakend/kong/tyc etc.) и к service mesh (istio etc.), а авторизация не доставляет проблем ни там, ни там.
Вполне возможно, что я где-то не прав, сужу чисто по личному опыту.
А что за закон-то? Что конкретно он запрещает или разрешает?
Тоже думал над этим, пока не приобрел MacBook. Оказалось на удивление удобно работать, видимо сказывается качественный экран.
Кстати, ещё одна из проблем - это контент 18+. В том же Second Life он занимает довольно значительную часть. Но в различных VR-метавселенных, типа VRChat, Sansar, Altspace и т. п., 18+ контент либо запрещен полностью, либо разрешен только в приватных зонах.
Жалко, что тот же Second Life, со всем его разнообразием контента, нельзя нормально адаптировать к VR, чисто из-за жестко фиксированных анимаций. Да развивается он откровенно черепашьими шагами, обладая при этом шлейфом застарелых багов и не проводя ни недели без падений.
Как вариант, можно написать скрипт или приложение, которое будет реагировать на свое имя файла. Для одного имени файла - какой-то безобидный функционал, для другого - дополнительно нечто вредоносное. Все равно практически никто не лазит с дизассемблером по файлам после их распаковки.
А в чем отличие этой штуки от Horizontal Pod Autoscale в Kubernetes, за исключением отсутствия привязки к Kubernetes?
Почему бы в данном случае не использовать на стороне базы данных тип даты-времени с сохранением часового пояса (`timestamp with time zone` /
timestamptzв Postgres)?Получится красиво: и сохранение локального времени независимо от локации, и возможность отображать его в произвольном часовом поясе, и правильная сортировка по данному полю.
Правда, не уверен, сохраняет ли тип
DateTimeв C# часовой пояс.Как вариант, можно парсить конфиг и проверять, нет ли чересчур больших значений для каких-нибудь параметров, которые могут уронить сервер. Есть пара библиотек для Go: [1], [2].
Сам когда-то давно писал парсер конфигов, только на сях. Написано криво-косо, но работает до сих пор :)
Знаете, чем мне не нравится передача ошибок (как в Go и Rust) и нравятся исключения?
Тем, что при передаче ошибок приложение становится гораздо сложнее отлаживать. Теряется информация, откуда именно пришла ошибка. При использовании исключений можно вывести stack trace до места, где возникло это самое исключение.
Тем, что невозможно заранее узнать, какие ошибки может возвращать функция. В принципе, с исключениями тоже не всегда можно узнать, какая функция какое исключение может кинуть, но обычно для этого есть если не языковые конструкции (как
throwsв Java), то хотя бы комментарии (как в PHP).Использование
panicв чем-то похоже на исключение, но не позволяет указать его тип — просто некая глобальная ошибка, которую можно где-то отловить, и все, что про нее известно, это ее текстовое описание.И все так же видео периодически подвисает (по крайней мере в Firefox), если кликать по времени туда-сюда.
Если вам не нужна асинхронщина, зачем вам здесь FastAPI? Flask тогда уж, благо он сихронный и имеет бОльшую популярность.
Окей. Какой смысл генерировать синхронно работающие методы при использовании асинхронного фреймворка?
Асинхронный - в смысле, с использованием
asyncio.Поможет это тем, что приложение не будет впустую ожидать, пока обработчик запроса получает данные из БД, а начнет обрабатывать в это время другой запрос.
Зачем брать асинхронный фреймворк, но при этом заставлять его работать синхронно? У SQLAlchemy недавно появился асинхронный режим работы, используйте его.
Насчет всеми любимой статьи 29… Пролистайте чуть ниже, до статьи 55:
Чувствуете расплывчатость формулировки, благодаря которой можно абсолютно законно наплевать на любую из статей 19-54?
Окей, если серьезно, то и те, и другие занимаются цензурой, в соответствие с какими-то своими принципами. Цензура — это и есть нарушение принципов свободного распространения информации и беспрепятственного доступа к ней. И довольно забавно видеть, как волк с окровавленной мордой кричит, что он против нарушений принципов вегетарианства.
Ну и разница в том, что одни (YouTube) еще как-то пытаются подстроиться под других, а эти самые другие (РосКомНадзор) плюют на все и делают, что хотят — решают, кого считать врагами народа, и периодически осуществляют блокировки значительной части интернета (все помнят про блокировки AWS и Google Public DNS?)
Там еще фурри предложили признать экстремистским движением :D Фурсьюты — угроза государству! :D
Ахахахахаххаахаааа :D