Решаване да не използваме GraphQl @defty Engineering — 3 неща, които открихме

Какво изграждаме

В defty ние сме на мисия да революционизираме създаването на уебсайтове за милиони малки предприятия с най-лесния за използване инструмент за създаване на уебсайтове.

Вместо да проектират уебсайт от нулата, собствениците на малък бизнес и частните лица ще могат да отговорят на няколко прости въпроса за своя бизнес и да имат привлекателен, отзивчив и оптимизиран за SEO сайт, генериран за тях. След това потребителят ще може да персонализира своя уебсайт и тема от всяко място, дори от мобилен телефон - всичко това без никакви технически или дизайнерски познания.

Поддържайки основния продукт, ние изграждаме табло за управление със система за домейни, платформа за електронна поща и администраторски контролен панел, който ще захранва всичко от удостоверяване до управление на клиенти.

Фокусиране върху таблото за управление

Целта ни е да достигнем до нашите клиенти до края на 2019 г., така че нашият инженерен фокус е върху изграждането на нещо здраво, бързо и ефективно. Искаме да останем достатъчно стройни, така че насочването на технологията към потенциалните бизнес нужди да не изисква преместване на твърде много инфраструктура.

В началото на планирането на таблото за управление започнахме бели бордови потенциални внедрявания, в този момент вече имахме спецификация на първоначалния набор от функции и технически обхват. Досега бяхме решили React, за фронтенд, Node/Express бекенд и Postgres база данни, това трябваше да бъде просто CRUD приложение, написано на Javascript, което ще обработва фактуриране, домейни, поддръжка и удостоверяване на потребителя.

Оценихме как може да изглежда нашият бекенд, два водещи избора, които се появиха, бяха REST бекенд и бекенд GraphQL. REST съществува от известно време и работи, но GraphQL е нова технология за нас, при това вълнуваща, така че разгледахме какво искаме от нея.

Предимства на GraphQL за таблото за управление

  • Бързо развитие — гъвкавост на интерфейса. Искахме да улесним разработването на предния край чрез опростяване на извличането на данни и потоците на състоянието.
  • Без свръхсъвпадение и недостатъчно извличане — GraphQL решава проблема с прекомерното и недостатъчното извличане на ресурси в API. Искахме да използваме този модел, за да имаме ефективни API повиквания с минимални разходи за честотна лента.
  • Богата екосистема и общност — От пускането си през 2015 г. GraphQL събра огромно количество последователи, използван е в производството от някои от най-големите компании в света, Facebook, Twitter, Pinterest и т.н. Разработени са различни инструменти, които улесняват живота. Инструменти като Apollo и Relay предоставят много функции като кеширане от кутията, а други инструменти като Prisma и graphql-yoga ви позволяват бързо да настроите схемата и сървъра на GraphQL. Искахме да се възползваме от тези мощни готови инструменти за изграждане, подиграване и наблюдение.
  • Силно типизиране — GraphQL се прилага с помощта на строго типизирана схема, която има много предимства, например позволява на API да бъде самоописателен, което кара клиента да знае какви данни са налични и в каква форма съществуват, както и позволява автоматично - генерирана документация. Искахме да използваме тези функции, за да ускорим документацията и като цяло да намалим потребителските грешки на API.

Разбихме го и зададохме някои важни въпроси

Решението дали да използваме GraphQL е важно решение, с което потенциално ще трябва да се придържаме дълго време. Погрижихме се да му отделим достатъчно време и внимание.

Взехме потенциална реализация на GraphQL, състояща се от React, Apollo клиент и сървър, graphql-yoga (включително Prisma) и Postgres и проучихме нейното приложение.

Първо разбрахме плюсовете и минусите на нашето внедряване на GraphQL и проучихме компромисите. Зададохме си важни въпроси, разглеждайки определени болезнени точки и случаи на употреба.

Някои важни въпроси, произлезли от него, бяха:

Колко сложност добавяме към бекенда, за да опростим предния край?

Как да спрем DoS атаки с помощта на неограничено дърво на заявки? Как да се справим с проблема N+1?

Как ще поддържаме тази архитектура в бъдеще?

Преминахме през няколко повторения на проучвателни въпроси и стигнахме до отговорите, докато достигнахме точка, в която се чувствахме комфортно с това, което намерихме, и можехме да направим заключение.

Какво научихме

1. Нямахме нужда от толкова много гъвкавост за допълнителната сложност

Едно от основните предимства на GraphQL и инструменти като Apollo е, че прави възможна бърза предна разработка чрез опростяване на извличането на данни и потоците на състоянието. Работи много добре в ситуации, в които нуждите от данни на клиента се променят постоянно, например на дневна или седмична база или с множество интерфейси. Таблото за управление, от друга страна, е просто CRUD приложение, където нуждите от данни са предвидимо постоянни, няма да имаме нужда от гъвкавост за допълнителната сложност.

2. Оптимизирането и сигурността добавиха допълнителна сложност

  • Решаване на проблема с данните N+1— Проблемът N+1 е често срещан проблем в GraphQL, като част от нашето изследване установихме, че използването на нещо като „зареждане на данни“ на Facebook би било решение за това, но добавя и допълнително ниво на сложността и времето за разработка на проект, който трябва да бъде относително ясен.
  • Сигурност — Установихме, че прилагането на защита срещу DoS атаки, използващи неограничени дървета на заявки, добави още един слой сложност. Има някои лесни за изпълнение решения като ограничаване на дълбочината и количеството. Въпреки това, за да осигурим пълно покритие при защита срещу злонамерени участници, ще трябва да приложим анализ на разходите за заявки. За да направим това, ще трябва да отделим много време за измерване на цената за всяка пермутация на заявка и задаване на правила за разходите за сложност, което допълнително увеличава времето за разработка и сложността.

3. Инженерното сглобяване не съвпаднало

Друг важен аспект при избора на правилната технология е колко добре тя се вписва в инженерните ресурси, с които разполагате. С GraphQL вие ефективно избутвате сложността от предния край към задния край и слоя база данни, екипът на таблото за управление е по-фокусиран върху предния край, така че преместването на сложността към задния край няма да работи за техните силни страни.

След всяка итерация на изследване осъзнахме, че разходите за инженерни инвестиции стават все по-големи и по-големи, че промяната на нещата по линията ще бъде по-трудна и просто не пасва на подхода, към който се стремим.

Заключение

Първоначално бяхме развълнувани да използваме GraphQL за таблото за управление, но това, което бързо открихме, беше, че това не е сребърният куршум за ПОЧИВКА, както някои вярват. Начинът, по който го разглеждаме, е алтернатива на бекендовете на REST, които имат значителни компромиси по отношение на сложността и инвестиционните разходи за инженеринг, но за просто табло за управление на CRUD, прост REST API, който се занимава с данни, които са относително последователни във времето, е правилен избор.

Това не означава, че не можем да го използваме в бъдеще

В крайна сметка бихме искали да използваме нещо ново и вълнуващо като GraphQL, възможно е да наслоим GraphQL върху REST бекенд заедно, така че ако изискванията за таблото за управление се променят, например, имаме нужда от изграждане на множество интерфейси или имаме данни изисквания, които се променят често, със сигурност ще изберем GraphQL!

TL;DR

Искахме да изберем правилната технология за продукта, който изграждаме, разгледахме внедряването на GraphQL като потенциално бекенд решение.

GraphQL е страхотен, но нямаше да можем да се възползваме от предимствата на добавената сложност, за да си заслужава, някои неща като оптимизацията добавят допълнителна сложност и не отговаряше на нашия инженерен подход и ресурси, които имаме. Все още можем да го използваме, ако изискванията ни се променят, но засега обикновен REST API работи най-добре.

„Ние наемаме“! Искате ли възможност да вземате важни инженерни решения като това в началото на живота на една компания? Посетете https://defty.com/jobs.html, за да разберете как да се присъедините към екипа и прочетете за големите предимства, които предлагаме.