Telegram Group & Telegram Channel
Шаринг типов между сервером и клиентом

Вчера в одном чатике задали вопрос на эту тему:> Вот смотрите, предположим, есть backend на питоне, есть UI на Angular. Оба используют контрактные (согласованные) структуры - бэк отдавая, фронт получая. Как мне подружить эти схемы, что б можно было вести только в одном месте ?

Тут у нас какие варианты, давайте по рассуждаем.

Первый идеальный. У нас на беке и фронте TS, поэтому проблемы как таковой и нет. Честно говоря, мне настолько понравилось последнее время делать проекты в этом стиле, что я бы в будущем так все проекты и делал. Особенно учитывая наличие великолепной drizzle orm в node.js (просто вау)

Второй энтерпрайзный. Описываем отдельную спеку в https://typespec.io/ затем из нее генерим не только типы, но и sdk для работы. Но такой подход тяжелее и больше используется для взаимодействия сервисов друг с другом, чем для клиент-серверного взаимодействия где это может быть оверкилом. Ну и на беке все равно будет связка “свои модели” - “сгенерированные dto” - “маппинги”, то есть рутины все равно достаточно.

Третий практичный. В этом варианте мы генерируем TS типы из наших моделей или dto (что правильнее). Как правило для бекенд фреймворков есть готовые либы https://github.com/skryukov/typelizer Если нет, то можно попросить chatgpt написать конвертер. Этот вариант не без изъянов, так как типы не мапятся один в один, то иногда в беке надо явно прописывать фронтендовые типы как строки. В https://code-basics.com выбран именно этот вариант.

Четвертый апишный. Генераторы на уровне описания самого апи в беке. То есть пишем апишку, добавляем мету и из нее генерим спеку, дальше из этой спеки можно уже типы для фронта https://drf-yasg.readthedocs.io/en/stable/. Возможно наиболее популярный путь, но такое точно не сработает с подходом аля inertia.js.

Четвертый рукпошка. Просто описываем типы независимо от бека и страдаем. Как ни странно, этот вариант не на последнем месте по популярности.

p.s. А как делаете вы и нравится ли вам такой подход?

Ссылки: Телеграм | Youtube | VK



group-telegram.com/orgprog/294
Create:
Last Update:

Шаринг типов между сервером и клиентом

Вчера в одном чатике задали вопрос на эту тему:> Вот смотрите, предположим, есть backend на питоне, есть UI на Angular. Оба используют контрактные (согласованные) структуры - бэк отдавая, фронт получая. Как мне подружить эти схемы, что б можно было вести только в одном месте ?

Тут у нас какие варианты, давайте по рассуждаем.

Первый идеальный. У нас на беке и фронте TS, поэтому проблемы как таковой и нет. Честно говоря, мне настолько понравилось последнее время делать проекты в этом стиле, что я бы в будущем так все проекты и делал. Особенно учитывая наличие великолепной drizzle orm в node.js (просто вау)

Второй энтерпрайзный. Описываем отдельную спеку в https://typespec.io/ затем из нее генерим не только типы, но и sdk для работы. Но такой подход тяжелее и больше используется для взаимодействия сервисов друг с другом, чем для клиент-серверного взаимодействия где это может быть оверкилом. Ну и на беке все равно будет связка “свои модели” - “сгенерированные dto” - “маппинги”, то есть рутины все равно достаточно.

Третий практичный. В этом варианте мы генерируем TS типы из наших моделей или dto (что правильнее). Как правило для бекенд фреймворков есть готовые либы https://github.com/skryukov/typelizer Если нет, то можно попросить chatgpt написать конвертер. Этот вариант не без изъянов, так как типы не мапятся один в один, то иногда в беке надо явно прописывать фронтендовые типы как строки. В https://code-basics.com выбран именно этот вариант.

Четвертый апишный. Генераторы на уровне описания самого апи в беке. То есть пишем апишку, добавляем мету и из нее генерим спеку, дальше из этой спеки можно уже типы для фронта https://drf-yasg.readthedocs.io/en/stable/. Возможно наиболее популярный путь, но такое точно не сработает с подходом аля inertia.js.

Четвертый рукпошка. Просто описываем типы независимо от бека и страдаем. Как ни странно, этот вариант не на последнем месте по популярности.

p.s. А как делаете вы и нравится ли вам такой подход?

Ссылки: Телеграм | Youtube | VK

BY Организованное программирование | Кирилл Мокевнин


Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260

Share with your friend now:
group-telegram.com/orgprog/294

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

"He has kind of an old-school cyber-libertarian world view where technology is there to set you free," Maréchal said. The original Telegram channel has expanded into a web of accounts for different locations, including specific pages made for individual Russian cities. There's also an English-language website, which states it is owned by the people who run the Telegram channels. Right now the digital security needs of Russians and Ukrainians are very different, and they lead to very different caveats about how to mitigate the risks associated with using Telegram. For Ukrainians in Ukraine, whose physical safety is at risk because they are in a war zone, digital security is probably not their highest priority. They may value access to news and communication with their loved ones over making sure that all of their communications are encrypted in such a manner that they are indecipherable to Telegram, its employees, or governments with court orders. It is unclear who runs the account, although Russia's official Ministry of Foreign Affairs Twitter account promoted the Telegram channel on Saturday and claimed it was operated by "a group of experts & journalists." Emerson Brooking, a disinformation expert at the Atlantic Council's Digital Forensic Research Lab, said: "Back in the Wild West period of content moderation, like 2014 or 2015, maybe they could have gotten away with it, but it stands in marked contrast with how other companies run themselves today."
from us


Telegram Организованное программирование | Кирилл Мокевнин
FROM American