О программисты! Костяк цифровой эры, незримые прядильщики нашей онлайн-вселенной. Боковая ветвь человекообразных приматов, связанных тесными родственными узами с Homo Sapiens. Отличаются плохой осанкой, лёгкой степенью мизантропии и способностью решить любую проблему, заглянув в Google. Это густонаселённое племя пестрит восхитительным разнообразием, которое чётко прослеживается в стилях программирования и личностных характеристиках.
При разработке больших web-проектов нам часто приходится взаимодействовать с API сторонних или внутренних микросервисов. Когда количество таких взаимодействий растёт, настройки вызовов к другому API и подробности самих вызовов кратно множатся и могут растекаться по проекту.
В Домклике у нас микросервисная архитектура, и каждому сервису приходится взаимодействовать с десятком других. Чтобы межсервисное взаимодействие было предсказуемым, надёжным, удобным и отслеживаемым, мы следуем ряду практик при разработке, и в этой статье я расскажу вам о них.
Hello world!
По данным 2023 JavaScript Rising Stars библиотека htmx заняла второе место в разделе Front-end Frameworks (первое место вполне ожидаемо принадлежит React) и десятое место в разделе Most Popular Projects Overall.
htmx — это библиотека, которая предоставляет доступ к AJAX, переходам CSS, WebSockets и Server Sent Events прямо из HTML через атрибуты, что позволяет создавать современные пользовательские интерфейсы (насколько сложные — другой вопрос), пользуясь простотой и мощью гипертекста. На сегодняшний день у библиотеки почти 30 000 звезд на Github. Удивительно, что до такого решения мы додумались только сейчас, учитывая, что весь функционал был доступен уже 10 лет назад (вы сами убедитесь в этом, когда мы изучим исходный код htmx).
В этой статье мы с вами разберемся, как htmx работает. Но давайте начнем с примера ее использования.
С точки зрения разработчика, объекты в JavaScript довольно гибкие и понятные. Мы можем добавлять, удалять и изменять свойства объекта по своему усмотрению. Однако мало кто задумывается о том, как объекты хранятся в памяти и обрабатываются JS-движками. Могут ли действия разработчика, прямо или косвенно, оказать влияние на производительность и потребление памяти? Попробуем разобраться во всем этом в этой статье.
Возможно, вы думаете, что о подписках говорить особо нечего. Они определены в спецификации GraphQL, и должно быть очень ясно, как они работают и для чего они нужны.
Но на самом деле спецификация мало что говорит о транспортном слое. Фактически, она вообще не указывает транспортный слой. С одной стороны, это преимущество, потому что вы можете использовать GraphQL в самых разных средах. С другой стороны, у нас сейчас есть по крайней мере пять разных реализаций подписок GraphQL.
Это означает, что вы не можете просто использовать любой клиент GraphQL, подключиться к серверу GraphQL и ожидать, что все будет работать. Вам нужно знать, какой протокол поддерживает сервер и какой клиент вам нужно использовать. Это идеальная ситуация? Вероятно, нет, но мы собираемся это изменить!
Мы - создатели WunderGraph (открытый исходный код), первого облачного серверного GraphQL API Gateway. Одной из проблем, с которой мы столкнулись, была поддержка всех различных протоколов подписки GraphQL. Поскольку спецификация GraphQL строго агностична к протоколу, за годы было разработано несколько различных протоколов.
Если клиент хочет использовать подписку GraphQL, ему нужно знать, какой протокол использовать, и реализовать клиентскую сторону этого протокола.
С нашим Open Source API Gateway, мы делаем шаг вперед и объединяем все под одной крышей. Если вы смотрите на использование подписок GraphQL в вашем проекте, этот пост - отличный способ быстро ознакомиться с различными протоколами и их особенностями.
Здравствуйте, меня зовут Дмитрий Карловский и я... ради лулзов создал самый мемный фреймворк в индустрии.
Если вы давно следите за моей работой, то знаете, что одним из моих любимых пристрастий являются сравнения GraphQL, REST, tRPC и других технологий, в которых не упоминаются Relay и Fragments. В этом посте я объясню, почему я считаю Relay переломным моментом, как мы сделали ее в 100 раз проще в использовании и внедрении, и почему вам стоит обратить на нее внимание.
В самом начале своей карьеры я имел честь в одно лицо разрабатывать проект, предназначенный для массового пользователя. Надо сказать, что почти все основополагающие принципы того, как провалить проект, были соблюдены, однако, он до сих пор жив. Проект был предназначен для принудительного использования определенной категорией работников бюджетной сферы. Технического задания, аналитики, дизайн-документов, макетов в Фигме, лавандового смузи, и прочих этих ваших модных слов, без которых N лет назад строили БАМ и Траннсиб не было от слова совсем. Зато, были процессы “в бумаге”, которые требовалось оцифровать. Поэтому то, что можно было принять за ТЗ, выглядело как “Эти (работники) заполняют вот это (бумаги) потом несут тем (проверяющим) а дальше все это хранится, сделай чтобы они с компьютера могли загрузить и отправить, у нас тут целый этаж бумагами занят, пожар начнется - всему хана”. Используя весь свой багаж знаний и опыта в построении высоконагруженных систем (на этом месте я отошел от написания статьи сначала проржаться а потом поплакать), я приступил к реализации.
«Сделай работающим, сделай правильным, сделай быстрым». Это мантра, которую вы, вероятно, слышали раньше. Это хорошая мантра, которая помогает вам сосредоточиться на том, чтобы не переусложнять решение. Я пришел к выводу, что обычно достаточно сделать это правильно, обычно это достаточно быстро, если сделать это правильно.
Когда мы начали реализацию подписок GraphQL в Cosmo Router, мы сосредоточились на том, чтобы сделать это работающим. Это было несколько месяцев назад. Это было достаточно хорошо для первой итерации и позволило нам получить отзывы от наших пользователей и лучше понять проблемное пространство.
В процессе того, как мы делали это правильно, мы сократили количество горутин на 99% и потребление памяти на 90% без жертвования производительностью. В этой статье я объясню, как мы достигли этого. Использование Epoll/Kqueue сыграло большую роль в этом, но также переосмысление архитектуры, чтобы она была более событийно‑ориентированной.
left-pad из нескольких строчек кода, которые реализуют примитивную функцию вставки пробелов в левой части строк. Он был установлен в качестве зависимости в React, Babel и других пакетах. Автор и мейнтейнер left-pad решил в знак протеста отозвать его, что вызвало массовый сбой в работе веб-сайтов. После этого компания npm Inc. запретила авторам отзывать свои пакеты без разрешения администрации.
Наша команда Mobile Doc&Loc «Лаборатории Касперского» занимается подготовкой документации и локализации B2C-продуктов компании для мобильных устройств. Основная сложность (и одновременно фишка) нашей работы заключается в том, что необходимо регулярно подготавливать переводы на 34 языка в крайне сжатые сроки.
Меня зовут Юлиана Соломатина, я — Doc&Loc-инженер, и в этой статье я расскажу про инструменты-автоматизации, которые помогают нам справляться с наплывом задач и укладываться в дедлайны, не жертвуя при этом качеством. Кстати, многие из этих инструментов мы разработали сами.
Сегодня я кратко (или не очень) изложу свои мысли о том, стоит ли быть fullstack разработчиком, какие плюсы и минусы у такого пути развития и для кого такое направление выгодно.
Сегодня трудно найти веб сайт, на котором нету хотя бы одного изображения, может быть у вас есть такой пример? На странице в интернете можно сразу увидеть много разных изображений: фото пользователя в личном кабинете, фото товара на маркетплейсе, иконка на вкладке браузера, иконка корзины на кнопке «добавить в корзину», анимированное изображение‑открытка от бабушки в мессенджере, [и еще тысяча примеров].
Если вы как‑то связаны с вебом то вам будет полезно иметь общее представление об этих images, как минимум, и уметь с ними работать как максимум. Давайте попробуем разобраться с этим вопросом?
Всем привет! В этой статье я хотел бы поделиться своими мыслями о том, почему виртуального DOM можно избежать при создании реактивности сегодня. Я работаю со всем этим уже около полутора лет, создавая фреймворк Cample.js, и у меня есть некоторые соображения по этому поводу.
Всем привет, на связи снова Арсений Елисеев! Продолжаем работу над созданием веб-приложения для управления бронью ЭЗС, которое мы начинали ранее: …. Сейчас мы обратим внимание на практические аспекты: построение математической модели метода, его программная реализация и экономическое обоснование разработанного ИТ-решения.
Привет всем, на связи Арсений Елисеев, я fullstack-разработчик в одном ИТ-интеграторе! Относительно недавно мы получили заказ на разработку веб-сервиса, который позволял бы нашим клиентам, владельцам электрокаров, строить маршруты и на их протяжении бронировать электронные зарядные станции под свои нужды. Я представил свою версию системы и хотел бы поделиться с вами ходом мыслей. Возможно, кто-то захочет прокомментировать мою модель или дать совет.
Что вам может дать продуктовый подход к pet-проекту? Если смотреть на pet-проект не как на лабораторную работу, а как на будущий продукт, начинаешь лучше понимать весь цикл разработки. При таком подходе ты сперва выступаешь в роли заказчика: определяешь, какую задачу пользователя решаешь, как это сделать наилучшим образом, а потом подбираешь технологии, которыми легче всего реализовать функционал или которые хочется попробовать. В тексте я расскажу о развитии моего pet-проекта по созданию музыкального стримингового веб-приложения и чему удалось научиться, используя данный подход.
