DRAFT: docs: #71: article#82
Conversation
| @@ -0,0 +1,380 @@ | |||
| На кого нацелена статья: | |||
There was a problem hiding this comment.
Overall note
Мне не до конца понятен вопрос про тему статьи, потому что по-моему указанная в начале цель полностью соответствует содержанию, и во время чтения у меня не было сомнений или ощущения, что я что-то не то читаю. Кажется, что даже человеку не в контексте из введения будет понятно, почему за эту задачу решили взяться.
Вплоть до ### Профили и скрипты читалось последовательно и логично, за исключением отдельных формулировок, которые можно было бы подправить (их выделю позже, надо еще раз пройтись по статье)
В разделе с подводными камнями очень нужно поправить много формулировок (в плане разбиения на предложения, последовательности слов и пр.), потому что частично было непонятно, что происходит, из-за написания. Особенно в третьем и четвертом камне.
И отследить, чтобы темы, о которых писалось в первой половине статьи и потом они возвращаются в "подводных камнях", логично расширялись в этом разделе, а не повторялись или противоречили. В плане повторения особенно мозг залагал на миграциях, потому что вроде мы их уже обсудили, вплоть до конфига алембика в коде, а потом хоп - описание флоу в камнях. В итоге "подводность" странная, потому что мы еще в самом начале пишем "такой-то инструмент понадобилось использовать для миграций", а ближе в концу объясняем, что это потому, что встроенного решения не было, и алембик стал вынужденным сторонним подключением (если я правильно поняла).
И с CMake в этом плане странновато получилось, потому что при описании стека мы про него вскользь сказали, как о само собой разумеющемся решении, а тут оказалось, что мы хотели его использовать по минимуму. Может, стоит оставить какую-то затравку на этот камень ещё в описании инструментов, может как-то по другому связать.
Первый камень с точки зрения повторения уже упомянутых идей стоит пересмотреть и законнектить с пред. разделами.
|
|
||
| С его помощью вы получаете готовую инфраструктуру API C++ бекенда: настроенную систему сборки под разные конфигурации, менеджер пакетов, библиотеку тестирования, пайплайн и миграции - остается лишь склонировать и попробовать, вдруг это подойдет и для вас. | ||
|
|
||
| Но до этого давайте разберемся, как появилась идея создания подобного шаблона. Ранее мы уже занимались разработкой чего-то подобного и в закромах своего GitHub имеем несколько шаблонов, которые вместе реализуют приложение для управления задачами - To-Dos. Кстати, один из них использовался в качестве примера в докладе нашего руководителя Александра, который проводил [воркшоп](https://techtrain.ru/talks/20004151/) на тему TDD разработки на фронтенде. |
There was a problem hiding this comment.
В следующем абзаце говорится "но для C++", и мне не хватило, чему вот это "но" противопоставляется, может стоит упомянуть, на каком стеке эти ранее созданные шаблоны были?
|
|
||
| Мы решили реализовать что-то похожее, но для C++, чтобы в будущем не тратить время на рутину, такую как настройку сборки, конфигурацию окружения и т.п., а быстро стартовать проект, подобно create-react-app, когда одной команды в терминале достаточно, чтобы перед тобой появилась готовая структура проекта со всем необходимым. | ||
|
|
||
| Наверное, каждый разработчик перед тем, как начать писать API backend на C++, задаётся вопросом - не делает ли он ошибку, выбирая такой язык, как C++, для реализации? Не будет ли правильнее взять что-то более современное и устоявшееся, как например .NET, NestJS или FastAPI? И если говорить начистоту, то в большинстве случаев сменить язык будет правильным выбором, но, несмотря на это, С++ имеет свои сильные стороны. |
There was a problem hiding this comment.
Бросилось в глаза сравнение языка с фреймворками (C++ vs .NET/NestJS/FastAPI). Понятно, что имеется в виду, но может стоить уточнить формулировку
|
|
||
| Мы решили реализовать что-то похожее, но для C++, чтобы в будущем не тратить время на рутину, такую как настройку сборки, конфигурацию окружения и т.п., а быстро стартовать проект, подобно create-react-app, когда одной команды в терминале достаточно, чтобы перед тобой появилась готовая структура проекта со всем необходимым. | ||
|
|
||
| Наверное, каждый разработчик перед тем, как начать писать API backend на C++, задаётся вопросом - не делает ли он ошибку, выбирая такой язык, как C++, для реализации? Не будет ли правильнее взять что-то более современное и устоявшееся, как например .NET, NestJS или FastAPI? И если говорить начистоту, то в большинстве случаев сменить язык будет правильным выбором, но, несмотря на это, С++ имеет свои сильные стороны. |
There was a problem hiding this comment.
| Наверное, каждый разработчик перед тем, как начать писать API backend на C++, задаётся вопросом - не делает ли он ошибку, выбирая такой язык, как C++, для реализации? Не будет ли правильнее взять что-то более современное и устоявшееся, как например .NET, NestJS или FastAPI? И если говорить начистоту, то в большинстве случаев сменить язык будет правильным выбором, но, несмотря на это, С++ имеет свои сильные стороны. | |
| Наверное, каждый разработчик перед тем, как начать писать API backend на C++, задаётся вопросом - не делает ли он ошибку, выбирая такой язык, как C++, для реализации? Не будет ли правильнее взять что-то более современное и устоявшееся, как например .NET, NestJS или FastAPI? И если говорить начистоту, то в большинстве случаев сменить язык будет правильным выбором, но несмотря на это, С++ имеет свои сильные стороны. |
|
|
||
| ### Компилятор | ||
|
|
||
| С компилятором повторилась похожая логика. MSVC отпал почти сразу, поскольку, как и в случае с vcpkg, не хотелось привязываться к конкретной платформе или IDE, а MSVC по сути жёстко связан с экосистемой Windows и Visual Studio. |
There was a problem hiding this comment.
Ко всему разделу инструментов относится: ссылки бы на упоминаемые опции (может на документацию или гл.страницу сайта). И расшифровки аббревиатур при первом упоминании (напр. я не знала, что Microsoft Visual C++ сокращается до MSVC...)
|
|
||
| ### Веб-фреймворк | ||
|
|
||
| В выборе веб-фремворка мы остановились на Drogon, поскольку, как нам показалось, у него низкий порог входа и понятный синтаксис. Из минусов можем отметить документацию, поскольку некоторые разделы содержат битые ссылки, что порой усложняет повествование и попытки найти нужный материал. |
There was a problem hiding this comment.
| В выборе веб-фремворка мы остановились на Drogon, поскольку, как нам показалось, у него низкий порог входа и понятный синтаксис. Из минусов можем отметить документацию, поскольку некоторые разделы содержат битые ссылки, что порой усложняет повествование и попытки найти нужный материал. | |
| В выборе веб-фреймворка мы остановились на Drogon, поскольку, как нам показалось, у него низкий порог входа и понятный синтаксис. Из минусов можем отметить документацию, поскольку некоторые разделы содержат битые ссылки, что порой усложняет восприятие и попытки найти нужный материал. |
или "усложняет изучение", или подобное
По смыслу логичнее, а то так будто вам сложнее излагать материал, а не читать его
|
|
||
| ### ORM | ||
|
|
||
| В качестве ORM системы изначально мы рассматривали те, что встроенны в фреймворки Drogon и Oat++, но в последствии отказались от этой идеи, поскольку они ориентированы на работу в формате SQL first, а не следуя паттерну Data Mapper, как нам хотелось. Кроме того, Drogon подразумевает, что база данных создаётся и наполняется таблицами вручную через SQL, и только после этого утилита drogon_ctl генерирует C++ классы моделей по уже существующей схеме, подключившись к базе. |
There was a problem hiding this comment.
| В качестве ORM системы изначально мы рассматривали те, что встроенны в фреймворки Drogon и Oat++, но в последствии отказались от этой идеи, поскольку они ориентированы на работу в формате SQL first, а не следуя паттерну Data Mapper, как нам хотелось. Кроме того, Drogon подразумевает, что база данных создаётся и наполняется таблицами вручную через SQL, и только после этого утилита drogon_ctl генерирует C++ классы моделей по уже существующей схеме, подключившись к базе. | |
| В качестве ORM системы изначально мы рассматривали те, что встроены в фреймворки Drogon и Oat++, но впоследствии отказались от этой идеи, поскольку они ориентированы на работу в формате SQL first, а не следуя паттерну Data Mapper, как нам хотелось. Кроме того, Drogon подразумевает, что база данных создаётся и наполняется таблицами вручную через SQL, и только после этого утилита drogon_ctl генерирует C++ классы моделей по уже существующей схеме, подключившись к базе. |
|
|
||
| В качестве ORM системы изначально мы рассматривали те, что встроенны в фреймворки Drogon и Oat++, но в последствии отказались от этой идеи, поскольку они ориентированы на работу в формате SQL first, а не следуя паттерну Data Mapper, как нам хотелось. Кроме того, Drogon подразумевает, что база данных создаётся и наполняется таблицами вручную через SQL, и только после этого утилита drogon_ctl генерирует C++ классы моделей по уже существующей схеме, подключившись к базе. | ||
|
|
||
| Также, в определенный момент рассматривали использование TinyORM, но быстро отказались из-за этой идеи, поскольку, как нам показалось, проект перестал поддерживаться, ведь последний коммит в репозитории был почти 2 года назад. |
There was a problem hiding this comment.
| Также, в определенный момент рассматривали использование TinyORM, но быстро отказались из-за этой идеи, поскольку, как нам показалось, проект перестал поддерживаться, ведь последний коммит в репозитории был почти 2 года назад. | |
| Также в определённый момент рассматривали использование TinyORM, но быстро отказались от этой идеи: как нам показалось, проект перестал поддерживаться, ведь последний коммит в репозитории был почти 2 года назад. |
(атаковала "поскольку", чтобы не было тавтологии со следующим абзацем и легче паузы при чтении расставлялись)
|
|
||
| В итоге мы остановились на ODB, поскольку, на наш взгляд, это более продвинутый инструмент, который позволяет работать с базой данных с помощью объектов и их методов, а не через SQL напрямую. | ||
|
|
||
| Стоит отдельно упомянуть про лицензию. ODB распространяется под GPLv2, что подразумевает открытый исходный код. В случаях, когда проект имеет лицензию более свободную, чем GPL (например, Apache или MIT), есть возможность по запросу получить персональную и более свободную версию лицензии. Code Synthesis, разработчик ODB, также предлагает бесплатную проприетарную лицензию (FPL) для небольших проектов, её можно получить, если объём сгенерированного кода поддержки базы данных в рамках одного релиза приложения не превышает 10 000 строк (~10-20 классов моделей). Для более крупных закрытых проектов потребуется приобрести коммерческую проприетарную лицензию (CPL). |
There was a problem hiding this comment.
не совсем уловила, почему из всех инструментов мы именно у ODB остановились на лицензии?
|
|
||
| Сервис `to-dos-api-cpp-karate-tests` собирается на основе образа с JRE, необходимого для запуска библиотеки тестирования Karate, которая распространяется в виде обычного `.jar`-файла. Сам `karate.jar` скачивается при сборке образа. После старта контейнера запускается выполнение e2e-сценария `to-dos-happy-path.feature`, который делает запросы к контейнеру `to-dos-api-cpp` и завершает работу с кодом, соответствующим результату выполнения тестов. | ||
|
|
||
| Конфигурация также содержит два профиля, позволяющих поднимать разный набор сервисов в зависимости от задачи: |
There was a problem hiding this comment.
Может где-то здесь стоит оставить источник, где можно подробнее про профили прочитать? (e.g. наша статья с Хабра)
Потому что кажется, что профили относятся к более продвинутым навыкам Docker Compose, и незнакомые с ними читателями могут прочитать и "стоп, что? какие профили?"
|
|
||
| ### Профили и скрипты | ||
|
|
||
| Хочется обратить внимание на некоторые тонкости, которые были внутри шаблона. |
There was a problem hiding this comment.
Мне кажется, лучше смысл этой фразы перенести в заголовок, т.е. обозначить, что это раздел про какие-то отдельные улучшения сетапа для улучшения dev experience (не уверена, насколько это правильное обобщение)
А уже внутри разделить на два подзаголовка про профили Conan и про скрипт.
There was a problem hiding this comment.
И может тогда стоит про скрипт чуть детальнее рассказать
3 participants
No description provided.