Одна из самых сложных задач разработчика - всегда спрашивать: «Подходит ли этот инструмент для работы?» и «Могу ли я лучше справиться с тем, что я делаю, используя другой инструмент?»
Признаюсь, сначала я был супер неуклюжим со всеми разными идеологиями. Трудно было понять, что то, что GraphQL создавал для меня (думая о моих данных в типах, которые всегда более естественны для меня), было конечной точкой REST. Единственная конечная точка, которая понимает, что такое запрос GraphQL, и возвращает запрос в форматированном ответе.
Продуктивность, полученная в результате размышлений о взаимосвязях между данными, была экспоненциально продуктивной по сравнению с традиционными подходами к моделированию баз данных и моделированию приложений. Оба одинаково важны, и поначалу обычно одного и того же типа. GraphQL позволил нам создать сервер, который общается по типам. Одно это сделало меня продуктивным и взволнованным.
Простота
Prisma (kudos) упростила границы службы базы данных и службы приложения (оба обычно находятся в одном приложении). Эти абстракции помогли нам понять, что мы хотим думать о наших данных и сервисах приложений в типах, и опять же, эти типы не исключают друг друга.
Недавно команда Prisma выпустила привязки, которые позволяют нам обмениваться данными между разными сервисами, используя знакомые конструкции и, в конечном итоге, объединяя схемы, обеспечивая единый источник запросов всех данных, на которых фокусируется наш домен.
Ничего себе, я был шокирован, насколько легко было разделить наши сервисы на знакомые конструкции микросервисов, не будучи неуклюжими или странными.
Это все еще ОТДЫХ
Самое интересное во всем этом: это все еще ОТДЫХ. Мне потребовалось некоторое время, чтобы смириться с этим. Когда я проверил сетевой трафик, все запросы направлялись к одной и той же конечной точке. Данные вернулись в едином формате. Это было упрощенно элегантно.
Prisma / Graph.cool - это круто!
Когда я только начал свое путешествие, graph.cool был одним из лучших способов начать работу с GraphQL, потому что он позволял мне мыслить типами и создавать базу данных, которая соответствовала бы моим типам.
Я должен признать, что преподавание graph.cool было потрясающим, потому что оно позволило моим ученикам начать думать о своих доменах, не зацикливаясь на мельчайших деталях баз данных, функций и т. Д.
По мере роста платформы graph.cool команда осознала, что хочет вернуть сообществу и открыть исходный код своей платформы. Сначала я скептически отнесся к предполагаемому предприятию. Я был потрясен, когда они выпустили версию Prisma 1.0, и она была другой, не такой привлекательной, как graph.cool, но по понятным причинам простой и элегантной в своем роде.
Я полюбил то, как Prisma думает о данных и как они работают. Я даже попробовал использовать TypeScript, чтобы получить некоторые преимущества их типов привязки, но все еще использую TypeScript, как JavaScript.
Используйте столько или меньше, сколько необходимо
Как и многие скептики, вы можете спросить, в чем же загвоздка. Нет ни одного. Поскольку он был построен на основе принципов, мы используем его, чтобы использовать столько или меньше, сколько вам нужно.
Это позволило нам взглянуть на наши REST api и обернуть конечные точки в тип GraphQL и сшить вместе модели данных, чтобы мы наконец могли видеть данные (я мог бы добавить только достаточное количество данных), не нанося вреда нашим старым унаследованным инструментам.
Разум взорван.
В своей работе я решил принять этот шаблон (поскольку наши отраслевые партнеры тоже начали его использовать) и обучать наших студентов. С моей точки зрения, это то, к чему мы идем. Наши студенты гораздо более ценны, если они хорошо знают GraphQL, реляционные базы данных и концепции моделирования данных. Мы приняли это и никогда не оглядывались назад.
Это одна из главных причин, почему у нас лучшие ученики в Helio Training.
