Мое путешествие в JSON до сих пор

В течение четырех лет я создавал приложения для Android, которые взаимодействуют с другими системами через JSON API — обычно это односторонние или двусторонние рукопожатия между моим приложением и сайтом или базой данных Drupal с использованием JavaScript Object Notation (JSON) в качестве общего языка.

Мое первое знакомство с JSON

Впервые я начал использовать JSON весной 2012 года после прохождения курса веб-разработки. До этого мои программы извлекали файлы содержимого XML. Они выполнили свою работу, но чувствовали себя немного неуклюже.

Я помню день, когда наш инструктор познакомил нас с JSON. Тот факт, что оно звучало как человеческое имя, каким-то образом делал его более представительным.

Когда я начал использовать его, я быстро обнаружил, что он более легкий и удобный для пользователя, но при этом остается таким же гибким, как XML.

В то время jQuery все еще был популярен, и на моем курсе мы привыкали к его использованию. «Помните, что знак доллара — это то, что приносит пользу jQuery», — посоветовал наш инструктор. «Никакого знака доллара, никакого добра с jQuery!»

Поэтому, когда я создавал свои первые веб-сайты и веб-интерактивы, я начал с использования jQuery для запросов JSON. Для интерактивов, подобных этой хронологии возникновения инфекционных заболеваний, я обрабатывал только один файл, поэтому мне не нужно было много думать о обратных вызовах.

От jQuery к ванильному JS

Со временем я начал отходить от jQuery и переключился на написание запросов с помощью ванильного JavaScript.

Толчком к этому стала масштабируемость. Я начал создавать приложения, которым нужно было не только извлекать и подготавливать файл JSON, но и извлекать его, загружать и использовать для захвата медиаресурсов в процессе загрузки нескольких файлов. НАМ нужно было заставить приложение работать в областях с низкой пропускной способностью и показывать прогресс.

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

По мере того, как JavaScript и я со временем совершенствовались, я начал больше узнавать о промисах и async / await. Я был очарован идеей писать запросы JSON так, как если бы они выглядели как асинхронный код. Я думал, что если вернуться к такому коду через шесть месяцев, его будет намного легче читать.

Я начал с постепенного изучения того, как создавать промисы, а затем продолжил изучение синтаксиса async / await. В течение следующих шести месяцев я переписал все свое приложение, удалив всю проводку jQuery JSON и заменив ее вызовами async / await и Promise.all(). По мере того, как я читал больше, я добавил try / catch блоков к своим async / await вызовам, что сделало мой код более надежным. По сей день я широко использую async / await с моими асинхронными вызовами, потому что, как только вы выходите за пределы своей собственной системы, вы просто никогда не знаете.

Это стоило потраченного времени. Оборачивая мои вызовы JSON в функции на основе Promise, которые я затем вызывал с помощью async / await, а затем немного защищал от ошибок с помощью try / catch, я произвел революцию в том, как я писал код, ориентированный на JSON, и постепенно я заменил большую часть моего кода, ориентированного исключительно на обратные вызовы, на асинхронный. функции.

Отправка данных

В первые дни мы просто хотели посмотреть, сможем ли мы заставить работать загрузку на основе приложения. Мы начали с отправки JSON на сервер, используя серверный PHP-скрипт для обработки каждого запроса и сохранения данных в виде инертных файлов. Хотя я с удовольствием оглядываюсь на эти первоначальные тесты, в то время они казались новаторскими. (Имейте в виду, дорогой читатель: я пришел к этому как фронтенд-разработчик.)

Когда мы наконец получили финансирование для приложения, которое должно было не только получать JSON, но и передавать JSON в базу данных для анализа, у меня была смесь недоверия, волнения и трепета. Может быть, и легкий ужас.

Со временем я работал с нашим инженером по базам данных, который говорил с SQL-запросами, как будто они были на родном языке, и создавал красивые информационные панели с помощью PowerBI.

После того, как мы собрали требования к приложению и разработали план загрузки в базу данных, я расширил свои вызовы JSON из запросов GET, и мы начали создавать запросы POST и PUT для обработки загрузки данных. Пока он создавал интерфейс прикладного программирования (API) — рукопожатие между моим приложением и его базой данных — я разработал функции, которые позволили приложению эффективно передавать данные.

Прежде чем мы узнали об этом, мое приложение, наше программное обеспечение базы данных и наше приложение для мониторинга загрузки каким-то образом использовали JSON для связи с нашими облачными серверами.

Результатом стал в основном гражданский диалог между эклектичной смесью устройств и серверных приложений. Например, кто бы мог подумать, что приложение со встроенным на 100% органическим JavaScript может вести такие поучительные диалоги с базой данных, построенной на C#.

И какой кривой обучения это было. Со временем я вынес несколько ключевых выводов по оптимизации диалога между моим приложением и базой данных.

выталкивание данных, состоящих из линейных лучей объектов, а не массивов с ключами, упрощает и делает более гибким выполнение запросов приложением базы данных. Внутри массива ключ оказывается в самом объекте.
сохранение статуса загруженного файла имеет важное значение для принятия решения о том, следует ли отправить существующий файл или разместить новый файл во время загрузки.
использование глобальных уникальных идентификаторов (GUID) стало незаменимым для сохранения уникальности среди объектов, которые выталкиваются.
использование комбинации мер безопасности, таких как использование ключей запроса в заголовках запросов, токенов и отправка идентификатора устройства, может сыграть важную роль в поддержании надлежащей безопасности и помочь нам спать по ночам.
использование облачных сервисов, таких как Azure, для мониторинга загрузки базы данных может очень помочь проверить, насколько быстро выполняется запрос и какие проблемы могут возникнуть.

Размышляя о нашей системе

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

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

В наши дни проблем, с которыми мы сталкиваемся, гораздо меньше, и по мере того, как мы продолжаем расширяться, я уверен, что будут сценарии, о которых мы не думали.

По мере того, как я продолжаю развивать платформу, я колеблюсь между принятием нашей существующей функциональности как должное и недоверием слушаю, как люди рассказывают о своих последних выводах о данных, загруженных системой, которая, похоже, действительно работает.

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

Учебники

Хотя я пишу учебники около полутора лет, я не решался написать один о том, как я подхожу к запросам JSON, потому что учебник по нему не казался достаточно самодостаточным. Кроме того, я не знал, откуда взять пример кода JSON.

Это изменилось, когда я обнаружил JSON Placeholder, в котором есть JSON без содержимого, из которого вы можете извлечь данные. Помимо приема запросов GET, этот поддельный API также обрабатывает запросы POST, PUT, PATCH и DELETE. И не бойтесь — даже если вы получите красивый ответ, вы не будете изменять реальную базу данных. Действительно, JSON Placeholder — идеальный ресурс для написания учебных пособий.

Что примечательно в анализе JSON, так это то, что помогает легко читаемый синтаксис. Например, я начал использовать for...of циклов для перебора массивов и for...in циклов для перебора объектов.

Я действительно считаю, что они отлично подходят для обхода массивов и объектов чистым и легко читаемым способом.

Прощальные мысли

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

Я понимаю, что многие приложения полагаются на библиотеки или фреймворки для запросов к серверу, но мне помогло научиться писать простые в использовании JSON-запросы просто с помощью Vanilla JS, особенно если фреймворк не поддерживается конкретным браузером. (Я смотрю на вас, Fetch и IE.)

Я надеюсь, что вы нашли эту статью полезной. Спасибо за чтение!