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

Сегодня мы рассмотрим использование диалоговых окон при редактировании данных в LibreOffice Base (OpenOffice Base). Как мы выяснили в предыдущих сообщениях, Форма LibreOffice Base (OpenOffice Base) — это фактически экземпляр текстового редактора LibreOffice (OpenOffice) Writer. Для организации оконного интерфейса внутри Формы используется Диалоги — которые удобно создаются во встроенным визуальном интерфейсе, но не имеют поддержки для связи с таблицами базы данных. Эту связь будем организовывать макросами OO Basic.

В части 2 будет рассмотрена связь между таблицами базы данных и формами. В частности как задавать связь между двумя таблицами и использовать таблицы-«справочники» в качестве источника данных для выпадающих списков.

В opensource офисных пакетах OpenOffice, LibreOffice есть редко используемая и очень скупо документированная возможность — программирование, которая позволяет быстро разрабатывать приложения, аналогичные, например, приложениям Microsoft Access. Сегодня я сделаю небольшой обзор возможностей программирования OpenOffice, LibreOffice.

К Load Balancers в системах оркестрации (Kubernetes, Nomad и других) предъявляется больше требований, чем просто балансировка нагрузки. Во-первых, Load Balancer должен уметь читать каталог со списком сервисов, на которые необходимо перенаправлять трафик (или, как вариант, давать возможность сервисам регистрироваться на включение их в трафик). Во-вторых, делать это динамически, т.к. системы оркестрации в любой момент могут увеличить или уменьшить количество реплик сервисов, или переместить их на другие адреса в сети. И, в-третьих, делать это без остановки трафика.

В сегодняшнем сообщении я опишу работу с двумя Load Balancers — Traefik и HAProxy. Эти Load Balancers имеют возможность работать с внушительным списком средств оркестрации. В примерах будет описана работа с системой оркестрации Nomad.

В настоящее время оркестрация контейнеров ассоциируется в первую очередь с kubernetes. Но это не единственный возможный выбор. Есть и альтернативные средства оркестрации, например nomad, разработчик HashiCorp (хорошо известный как разработчик средства виртуализации Vagrant).

Осваивать работу с средствами оркестрации как правило сложно, т.к. не у всех имеется доступ к инфраструктуре из нескольких серверов с рутовым доступом, поэтому, в предыдущем посте
Разворачиваем Kubernetes на десктопе за несколько минут с MicroK8s был описан процесс разворачивания среды Kubernetes на десктопе на примере веб-приложения Django. Первоначально я планировал в продолжении описать разворачивание базы данных в среде MicroK8s. Но потом подумал, чтоб будет интересно продолжить работу с не менее удобным средством оркестрации nomad. Я не буду давать даже намека на сравнение разных систем оркестрации. Единственное замечу для тех кто сомневается, что nomad установить еще проще чем MicroK8s, т.к. для этого нужно просто скопировать два исполняемых файла (nomad и consul) с сервера разработчика.

Начать работать с Kubernetes не всегда бывает просто. Не у всех есть необходимая для разворачивания полноценного кластера Kubernetes инфраструктура. Для локальной работы Kubernetes предлагет утилиту Minikube. Minikube — достаточно простое и удобное средство, и есть несколько обучающих курсов по работете с Minikube. Но, все же, о Minikube нельзя сказать, что с помощью этой утилиты можно за несколько минут развернуть среду Kubernetes.

Сегодня я хочу рассказать о пакете MicroK8s, который без преувеличения позволяет развернуть Kubernetes локально за несколько минут, и начать разработку. Не требуется даже предустановленных Docker и Kubernetes, т.к. все включено. В предлагаемом Вам уроке будет рассмотрен деплой приложения Django в локальной среде Kubernetes.

В качестве источника я шел вслед за серией статей Mark Gituma, в которых описана аналогичная работа, но только с Minikube, а не с MicroK8s.

Все же есть одно требование, которое необходимо удовлетворить до начала работы. У Вас должен быть установлен Snap, что в свою очередь означает, что у Вас должен быть установлен Linux.

Недавно мне передали на поддержку проект на express.js. При изучении кода проекта я обнаружил немного запутанную работу с аутентификацией/авторизацией которая базировалась, как и 99,999% случаев, на библиотеке passport.js. Этот код работал, и следуя принципу «работает — не трогай», я оставил его как есть. Когда через пару дней мне дали задание добавить еще две стратегии авторизации. И тогда я начал вспоминать, что уже делал аналогичную работу, и это занимало несколько строк кода. Полистав документацию на сайте passport.js, я почти не сдвинулся с места в понимании того, что и как нужно делать, т.к. там рассматривались случаи, когда используется ровно одна стратегия, для которой, для каждой в отдельности, и даются примеры. Но как соединить несколько стратегий, зачем нужно использовать метод logIn() (что то же самое, что login()) — по-прежнему не прояснялось. Поэтому, чтобы разобраться сейчас, и не повторять тот же поиск еще и еще раз, — я составил для себя эти заметки.

Поддержание документации к микросервисам в актуальном состоянии по прежнему требует предельной дисциплины при разработке, ну и больших трудозарат. Очень разумный подход к созданию документации предлагает, например, GraphQL, где документация неразрывно связана с программным кодом и этим гарантируется 100% соответствие документации и документируемых сервисов. Однако, непривычность подхода GraphQL для разработчиков, привыкших к REST-API, все еще затрудняет продвижение этой технологии в практическую разработку приложений. Тут же можно вспомнить и SOAP, который уже давно решил проблему соответствия документации и сервисов, но из-за переусложненности не прижился в широких массах разработчиков.

Хотелось бы найти такой стек технологий для разработки микросервисов, который обеспечил такую же самодокументируемость программного кода при разработке «традиционных» REST-API микросервисов. И он, как оказалось, уже существует.

В этом сообщении будут рассмотрены способы соединения коллекций в NoSQL базах данных mongodb, arangodb, orientdb и rethinkdb (помимо того, что это NoSQL базы данных, их объединяет еще и наличие бесплатной версии с достаточно лояльной лицензией). В реляционных базах данных аналогичная функциональность реализуется при помощи SQL JOIN. Несмотря на то, что CRUD — операции в NoSQL базах данных очень похожи и различаются только в деталях, например, в одной базе данных для создания объекта используется функция create({… }), в другой — insert({… }), а в третьей — save({… }), — реализация выборки из двух и более коллекций в каждой из баз данных реализована совершенно по-разному. Поэтому будет интересно выполнить на всех базах данных одинаковую выборку. Для всех баз будет рассмотрено получение выборки (связь типа многие-ко многим) для двух таблиц.

При работе с базами данных существует проблема которую принято называть «SELECT N + 1» — это когда приложение вместо одного запроса к базе данных, который выбирает все необходимые данные из нескольких связанных таблиц, коллекций, — делает дополнительный подзапрос для каждой строки результата первого запроса, чтобы получить связанные данные. Например, сначала мы получаем список студентов университета, в котором его специальность обозначена идентификатором, а потом для каждого из студентов делаем дополнительный подзапрос в таблицу или коллекцию специальностей, чтобы по идентификатору специальности получить наименование специальности. Поскольку каждый из подзапросов может потребовать еще один подзапрос, и еще один подзапрос — колчество запросов к базе данных начинает расти в геометрической прогрессии.

При работе с graphql очень просто породить проблему «SELECT N + 1», если в resolver-функции сделать подзапрос к связанной таблице. Первое что приходит в голову — сделать запрос сразу с учетом всех связанных данных, но это, согласитесь, нерационально, если связанные данные не запрашиваются клиентом.

Один из вариантов решения проблемы «SELECT N + 1» для graphql будет рассмотрен в этом сообщении.

В предыдущем сообщении Apollo graphql client применялся для разработки чисто клиентского приложения. В документации Apollo graphql client есть (очень лаконичный) раздел, посвященный серверному рендерингу и изоморфным приложениям.

Одна из сложностей серверного рендеринга в react.js является необходимость асинхронной загрузки данных, т.к. серверный рендеринг в reaсt.js — операция синхронная. Например, фреймверк next.js предлагает для этого использовать специальный компонент page в котором реализован дополнительный метод static async getInitialProps(), в котором предлагается проводить асинхронную загрузку данных. Такое решение не лишено недостатков. Например, этот метод статический, следовательно не имеет доступ к экземпляру компонента, метод реализован только для компонента самого верхнего уровня и отсутствует у вложенных компонентов. Решение с Apollo graphql client может быть использовано для компонента произвольного уровня вложенности.

Появившиеся в JavaScript новые асинхроные конструкции async/await выглядят проще, чем Promise, и, конечно, значительно читабельнее, чем «callback-джунгли». Но одна вещь беспокоила меня — это использование try-catch. Сначала я подумал, что это не проблема, но, к несчастью, мне пришлось работать с цепочкой вызовов API, в которой каждый вызов API имел свое сообщение об ошибке, которое должно было прологировано. Вскоре я понял, что создаю «try/catch-джунгли», которые ничем не лучше «callback-джунглей».

Apollo graphql client представляет удобный лаконичный спсоб работы с данными в приложениях react. В большинстве случаев все то, что мы привыкли делать с помощью redux, гораздо проще сделать при помощи Apollo graphql client. То, о чем я хотел бы рассказать в этой статье — это что связка react + apollo client + graphql существенно (на порядок) упрощает разработку приложений react.

В это статье будет сделан обзор возможностей модуля Nchan веб-сервера nginx, который заменил deprecated модуль NGiNX_HTTP_Push_Module. Модуль Nchan поддерживает основные технологии отправки сообщений Websocket, EventSource (Server-Sent Events), Long-Polling. Для горизонтального масштабирования используется кластер серверов redis.

Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL

By Jakob Holdgaard Thomsen
January 12, 2016

https://eng.uber.com/schemaless-part-one/



Проектирование Schemaless хранилища данных Uber Engineering с использованием MySQL. Это первая часть из трех частей серии статей о Schemaless хранилище данных.

В Project Mezzanine мы описали, как мы перенесли данные о поездках Uber из одного экземпляра Postgres в Schemaless — наше высокопроизводительное и надежное хранилище данных. В этой статье описывается его архитектура, роль в инфраструктуре Uber и история проектирования.

Для поиска нужной информации на веб-сайтах и в мобильных приложениях часто используется поиск по словам или фразам, которые пользователь свободно вводит с клавиатуры (а не выбирает например из списка). Естественно, что пользователь может допускать ошибки и опечатки. В этом случае полнотекстовый поиск, полнотекстовые индексы, которые реализованы в большинстве баз данных не дают ожидаемого результата и практически бесполезны. Такой функционал все чаще реализуют на основе elasticsearch.

Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска.

Когда я расположил приложение в Docker-контейнере и попробовал отправить email на почтовый сервер в другом Docker-контейнере, столкнулся с непредвиденной проблемой. Почтовый сервер postfix по умолчанию отправляет почту на произвольный домен получателя только от локального клиента. Все остальные домены нужно прописывать в параметре relay_domains, и если параметр mynetwors настроен правильно, то почта будет отправляться на перечисленные в параметре relay_domains домены с клиента из mynetwors.

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

При разработке модульных тестов для react компонента, обернутого в вызов withRouter(Component) столкнулся с сообщением об ошибке, что такой компонент может существовать только в контексте роутера. Решение этой проблемы очень простое и не должно по идее вызывать вопрсов. Хотя почему-то ссылки на документацию https://reacttraining.com/react-router/web/guides/testing Google упорно отказывался выдавать. Меня это совсем не удивляет, т.к. документация написано как чистое SPA-приложение без всякого там SSR и с точки зрения поисковой машины выглядит вот так:


Кому достаточно документации может на этом закончить чтение. А для себя я сделаю несколько заметок под катом.

25 февраля 2018 года вышел релиз webpack 4.0.0 (и на сегодняшний день 4.0.1). Одна из полезных и сравнительно новых фич webpack — code splitting, перенесена в новой версии из плагинов в основную конфигурацию. При практически полном отсутствии документации, как теперь нужно конфигурировать code splitting в версии 4 — я немного испытал шок, но все же попытался собрать информацию, чтобы по минимуму начать работать с новой версией. Я надеюсь, что через некоторое время появятся и обстоятельные tutorials, и статьи. Пока же спешу сделать заметки по найденной информации, чтобы не потерять ее на просторах интернета.