Drupal-ը որպես backend․ GraphQL, JSON:API, RESTful և թանկարժեք սխալը, որը թաքնված է API-ի ընտրության մեջ

Մի անգամ մի CTO, decoupled Drupal-ի պլանավորման հանդիպման կեսին, ինձ հարցրեց․ «Այսինքն՝ ո՞ր API-ն պետք է օգտագործենք»։

Սենյակը մի վայրկյան լռեց։ Frontend-ը ուզում էր GraphQL։ Backend-ը ուզում էր JSON:API։ Ինտեգրման մի vendor արդեն ենթադրել էր REST։ Product owner-ը պարզապես ուզում էր, որ բջջային հավելվածը դադարի սպասել կայքի release-ներին։

Այդ փոքր հարցը սովորաբար տեխնիկական է հնչում։ Բայց այդպես չէ։ Դա governance-ի հարց է, բյուջեի հարց է, և երբեմն՝ աշխատանքի ընդունման հարց՝ developer-ի hoodie հագած։

Drupal-ը կարող է լինել շատ կարող backend decoupled արտադրանքների համար։ Այն արդեն ունի կառուցվածքային բովանդակություն, դերեր, թույլտվություններ, workflows, revisions, թարգմանություններ, մեդիայի կառավարում, taxonomy և հասուն module ecosystem։ Անհարմար մասը որոշելն է, թե ինչպես է այդ բովանդակությունը դուրս գալիս Drupal-ից։ Drupal core-ը ունի JSON:API-ի native support, GraphQL-ը հասանելի է contributed module-ի միջոցով, իսկ Drupal-ի RESTful Web Services module-ը շարունակում է մնալ տարբերակ custom resource-style endpoint-ների համար։ Drupal-ի սեփական decoupled documentation-ը բաժանումը պարզ է ձևակերպում․ JSON:API-ն core-ում է, GraphQL-ը contributed է, և Drupal-ը կարող է API-ների միջոցով բովանդակություն տրամադրել արտաքին frontend-ին։

Եվ այնուամենայնիվ թիմերը դեռ սխալ են ընտրում։

Նրանք ընտրում են GraphQL, որովհետև այն ժամանակակից է հնչում։ Նրանք ընտրում են REST, որովհետև բոլորը այն օգտագործել են։ Նրանք ընտրում են JSON:API, որովհետև այն արդեն կա։ Դրանցից ոչ մեկը ռազմավարություն չէ։

Ահա ավելի սուր տարբերակը․ Drupal-ի վրա կառուցված բովանդակային հարթակների մեծ մասի համար JSON:API-ն պետք է լինի լռելյայն մեկնարկային կետը։ GraphQL-ը պետք է վաստակել։ REST-ը պետք է պահել այն դեպքերի համար, երբ մյուս երկուսը չափազանց լայն են կամ չափազանց opinionated։

Սա որոշ մարդկանց կնյարդայնացնի։ Լավ։

Սկսեք ձանձրալի հաղթողից՝ JSON:API

JSON:API-ն ձանձրալի է հնարավոր լավագույն իմաստով։

Drupal-ի core JSON:API module-ը իրականացնում է JSON:API specification-ը Drupal entities-ի համար։ Այն տալիս է zero-configuration, opinionated եղանակ՝ կայքի բովանդակության CRUD գործողությունները expose անելու համար, և կապված է Drupal-ի Entity API-ի, Field API-ի, caching-ի, authentication-ի և authorization systems-ի հետ։

Այդ նախադասության մեջ կա այն մասը, որը պետք է հետաքրքրի ղեկավարներին․ core module։

Core-ը կարևոր է։ Core-ը սովորաբար նշանակում է ավելի քիչ vendor surprises, ավելի հեշտ maintenance planning, ավելի պարզ security posture և ավելի քիչ ռիսկ՝ «մեզ պետք է այն միակ contractor-ը, որը հասկանում է custom API layer-ը» ձևաչափով։ Drupal-ի JSON:API documentation-ը ասում է, որ module-ը APIs է expose անում entity types-ի և bundles-ի շուրջ, աջակցում է filtering, includes, pagination, sorting, revisions, translations, GET, POST, PATCH, DELETE, file uploads և resource customization՝ events-ի միջոցով։

Գործնական օրինակ․ պատկերացրեք մեդիա ընկերություն՝ հոդվածներով, հեղինակներով, թեմաներով, landing-page teaser-ներով և պատկերներով։ Frontend թիմին պետք են հոդվածների էջեր Next.js-ում։ Բջջային հավելվածին պետք է նույն article body-ն, hero image-ը, հեղինակի անունը և related topics-ը։ JSON:API-ն կարող է expose անել այդ Drupal entities-ը՝ առանց backend թիմին ստիպելու զրոյից հորինել API language։ Related resources-ը կարող են embedded լինել includes-ի միջոցով, իսկ collections-ը կարող են filtered կամ paginated լինել։

Payload-ը գեղեցի՞կ է։ Երբեմն։ Երբեմն այն կարծես մի հանձնաժողով է նախագծել երկար ճաշից հետո։

Բայց դա նույնպես է իմաստը։ JSON:API-ն specification է, ոչ թե developer-ի անձնական ճաշակը։ JSON:API-ի պաշտոնական կայքը այն նկարագրում է որպես specification՝ JSON-ում APIs կառուցելու համար, shared conventions-ով, որոնք նվազեցնում են response shape-ի շուրջ վեճերը և օգնում թիմերին օգտագործել ընդհանուր tooling։ Դրա media type-ն է application/vnd.api+json, իսկ version 1.1-ը վերջնականացվել է 2022 թվականի սեպտեմբերի 30-ին։

Այստեղ կա թաքնված management benefit։ Ստանդարտացված response format-ը նշանակում է, որ onboarding-ը պակաս tribal է։ Նոր frontend developer-ը կարող է դեռ դժգոհել nested data, attributes և relationships structure-ից։ Լավ։ Գոնե նա դժգոհում է մի բանից, որը documented է։

Այն թակարդը, որի մասին ոչ ոք չի ուզում խոսել

JSON:API-ն բավականին ուղղակի expose է անում Drupal-ի content model-ը։ Դա կարող է ուժեղ կողմ լինել, հատկապես երբ Drupal-ը editorial source of truth է։ Բայց դա կարող է նաև չափազանց շատ բացահայտել Drupal-ի ներքին կառուցվածքը frontend-ին։

Եթե ձեր content model-ը մաքուր է, JSON:API-ն արդյունավետ է թվում։ Եթե ձեր content model-ը հին զիջումների թանգարան է, JSON:API-ն տեսանելի է դարձնում խառնաշփոթը։

Ես տեսել եմ “Article” content types՝ այնպիսի fields-ով, ինչպիսիք են field_new_body_2021, field_mobile_summary, field_legacy_related և field_do_not_use։ JSON:API-ն դա կախարդական կերպով չի դարձնում գեղեցիկ product API։ Այն expose է անում այն model-ը, որն իրականում ունեք։ Մի քիչ դաժան, գուցե։ Բայց օգտակար։

Drupal-ի documentation-ը նաև հստակ սահման է գծում․ JSON:API-ն զբաղվում է entity-oriented CRUD-ով, բայց business rules-ը, ինչպիսիք են login-ը, password reset-ը և account creation-ը, JSON:API-ի գործը չեն։ Եթե ձեր application-ին պետք են domain actions, ինչպիսիք են «հաստատել vendor-ին», «հաշվել renewal quote-ը» կամ «ներկայացնել claim», մի ստիպեք դրանք մտնել content-entity endpoint-ների մեջ միայն այն պատճառով, որ module-ը հարմար է։

Այդ ճանապարհը արագ տգեղ է դառնում։

GraphQL-ը էլեգանտ է թվում, որովհետև ցավը տեղափոխում է

GraphQL-ը գայթակղիչ է։ Frontend-ը խնդրում է հենց այն fields-ը, որոնք ուզում է։ Response-ը ունի նույն shape-ը, ինչ query-ն։ Այն ունի typed schema։ Այն կարծես նախագծված է component-based frontends-ի համար, որովհետև, անկեղծ ասած, հենց այդպես էլ եղել է։ GraphQL-ի պաշտոնական կայքը GraphQL-ը նկարագրում է որպես open-source query language և server-side runtime APIs-ի համար՝ strongly typed schema-ով, և ցույց է տալիս, թե ինչպես client-ը խնդրում է selected fields՝ fixed server response ստանալու փոխարեն։

Frontend թիմերի համար դա իրական բարելավում է։

Վերցրեք homepage՝ բաղկացած components-ից․ hero, featured articles, events, sponsor slots, navigation, regional alerts։ REST-ի դեպքում frontend-ը կարող է կանչել մի քանի endpoints։ JSON:API-ի դեպքում այն կարող է request անել collection և include անել related resources, բայց structure-ը դեռ հետևում է entity relationships-ին։ GraphQL-ի դեպքում query-ն կարող է ավելի մոտ լինել էկրանին։ Դա կարևոր է, երբ թիմերը արագ են թողարկում product surfaces։

Drupal-ի GraphQL module-ը developers-ին թույլ է տալիս craft և expose անել GraphQL schema Drupal 10-ի և 11-ի համար։ Այն կառուցված է webonyx/graphql-php-ի շուրջ, աջակցում է պաշտոնական GraphQL specification-ին, ներառում է GraphiQL՝ /graphql/explorer հասցեում, և developers-ին տալիս է data producer plugins, ինչպես նաև custom code schema աշխատանքի համար։

Զգուշորեն կարդացեք ձևակերպումը՝ «craft և expose»։

Ներկայիս Drupal GraphQL module-ը կախարդական հայելի չէ, որը պարզապես արտացոլում է Drupal-ի յուրաքանչյուր field կոկիկ API-ի մեջ։ Drupal.org-ը ասում է, որ ավելի հին 3.x version-ը ավտոմատ կերպով schema էր generate անում Drupal entities-ից և expose էր անում Drupal details-ը API-ի միջոցով, մինչդեռ 4.x-ը schema design-ը թողնում է developer-ին, որպեսզի Drupal internals-ը հնարավոր լինի թաքցնել։ Նույն էջը ասում է, որ 4.x-ը developer-ից պահանջում է setup և map անել schema-ն։

Դա footnote չէ։ Դա invoice-ն է։

GraphQL-ը կարող է ձեզ տալ մաքուր contract product-ի և content storage-ի միջև։ Բայց ինչ-որ մեկը պետք է design անի այդ contract-ը։ Ինչ-որ մեկը պետք է maintain անի այն, երբ editors-ը fields են ավելացնում, երբ design system-ը փոխվում է, երբ personalization-ը գալիս է, երբ legal-ը regional consent logic է պահանջում, երբ mobile team-ին պետք է offline sync։

Իրականում, դա չափազանց քաղաքավարի է։ Ինչ-որ մեկը պետք է own անի դա։ Ownership-ը GraphQL-ի շատ proposals-ում բացակայող line item-ն է։

Երբ GraphQL-ը արժե իր արժեքը

GraphQL-ը իմաստ ունի, երբ API-ն ինքնին product է։

Մեծ համալսարանը՝ տասնյակ microsites-ով, student mobile app-ով, digital signage-ով, faculty profiles-ով, course catalogs-ով և design system-ով, կարող է օգուտ ստանալ GraphQL layer-ից։ Consumers-ը բազմազան են։ Content graph-ը խորն է։ Frontend teams-ին պետք է selective access։ Կազմակերպությունը կարող է ցանկանալ API contract, որը թաքցնում է Drupal bundles-ի տարօրինակությունները։

GraphQL-ը նաև համապատասխանում է, երբ Drupal-ը մի քանի աղբյուրներից միայն մեկն է։ Գուցե content-ը գալիս է Drupal-ից, prices-ը՝ ERP-ից, availability-ն՝ booking engine-ից, իսկ user entitlements-ը՝ CRM-ից։ GraphQL-ը կարող է clients-ին ներկայացնել coherent schema, մինչ resolvers-ը fetch են անում տարբեր systems-ից։ GraphQL model-ը կառուցվել է strongly typed schema-ի և client-specified response shape-ի շուրջ, և հենց դա է պատճառը, որ այն լավ է աշխատում այսպիսի composition layer-ում։

Բայց սովորական marketing site-ի համար headless frontend-ով՞։ Ես սկեպտիկ կլինեի։ Նույնիսկ մի փոքր նյարդայնացած։

Եթե իրական կարիքն է՝ «React-ը պետք է հոդվածներ կարդա Drupal-ից», GraphQL-ը կարող է լինել դիմակահանդես։ Դուք կծախսեք architecture money՝ JSON:API includes և filters սովորելուց խուսափելու համար։ Ավելի վատ՝ կարող եք ստեղծել bespoke API layer, որը միայն երկու developer են հասկանում։

Drupal GraphQL project page-ը հայտնում է, որ stable releases-ը covered են Drupal-ի security advisory policy-ով և թվարկում է Drupal 10-ի և 11-ի recent releases-ը, ներառյալ 8.x-4.14-ը, որը released է 2026 թվականի ապրիլի 29-ին, և 5.0.0 beta-ն Drupal 10.4-ի և 11-ի համար։ Դա առողջ նշան է։ Բայց այն չի հեռացնում design work-ը։

Contributed module-ը կարող է mature լինել և միևնույն ժամանակ լինել սխալ default։

RESTful Web Services․ հին, օգտակար և սովորաբար չափազանց շատ օգտագործվող

REST-ը դարձել է այն բառերից մեկը, որը նշանակում է այն, ինչ խոսողին տվյալ պահին պետք է։ Երբեմն դա նշանակում է մաքուր resource-oriented HTTP։ Երբեմն նշանակում է՝ «մենք JSON ենք վերադարձնում controller-ից»։ Երբեմն նշանակում է՝ «vendor-ը մեզ endpoint և PDF է տվել»։

Roy Fielding-ի dissertation-ը REST-ը ներկայացրեց որպես architectural style distributed hypermedia systems-ի համար՝ constraints-ով, ինչպիսիք են client-server separation-ը, stateless communication-ը, cache-ը, uniform interface-ը, layered systems-ը և optional code-on-demand-ը։ Այդ սկզբնական գաղափարը ավելի խիստ է, քան այն շատ բաները, որոնք project plans-ում կոչվում են REST։

Drupal-ի RESTful Web Services module-ը օգտակար է, որովհետև կարող է expose անել resources՝ specific methods-ով, serialization formats-ով և authentication-ով։ Drupal study material-ը նկարագրում է REST resources entities-ի համար, աջակցություն methods-ի համար, ինչպիսիք են GET, POST, PATCH և DELETE, JSON կամ XML serialization, և authentication՝ Basic Auth-ի, cookies-ի կամ այլ modules-ի միջոցով, օրինակ՝ OAuth։ Այն նաև նշում է, որ unsafe methods-ը պահանջում են X-CSRF-Token request header։

Սա REST-ը լավ է դարձնում նեղ integration work-ի համար։

Payment provider-ը transaction status է post անում Drupal-ին։ Warehouse system-ը pulls է անում updated product manuals-ի list։ Partner portal-ին պետք է մեկ carefully shaped endpoint approved assets-ի համար։ Legacy mobile app-ը արդեն expects է /api/v1/articles/{id} և չի կարող rewritten լինել այս quarter-ում։

REST-ը ձեզ control է տալիս։ Այն նաև տալիս է blank-page syndrome։

Ի տարբերություն JSON:API-ի, որտեղ conventions-ը արդեն ընտրված են, custom REST endpoint-ը պահանջում է որոշումներ՝ URL shape, response format, error format, pagination style, filtering syntax, versioning, authentication, cache headers, documentation, deprecation policy։ OpenAPI-ն կարող է օգնել document անել այդ surface-ը, իսկ OpenAPI Specification-ը standard, language-agnostic միջոց է HTTP APIs նկարագրելու համար, որպեսզի մարդիկ և համակարգիչները կարողանան հասկանալ դրանք առանց source code կարդալու։

Այնուամենայնիվ, դուք պետք է ընտրություններ կատարեք։

Եվ այդ ընտրությունները մնում են։ Երկրորդ շաբաթում sloppy նախագծված endpoint-ը կարող է տարիներով հետապնդել product-ին, որովհետև որևէ app version, որը դեռ օգտագործման մեջ է, շարունակում է կախված լինել դրանից։

Որոշումը «ո՞ր API-ն է լավագույնը» չէ

Այդ ձևակերպումը ծույլ է։ Կներեք, բայց այդպես է։

Ավելի լավ հարցն է․ ձեր կազմակերպությունը coupling-ի ո՞ր տեսակն է կարող իրեն թույլ տալ։

JSON:API-ն consumers-ին կապում է Drupal-ի entity model-ին։ Դա հաճախ ընդունելի է, երբ Drupal-ը հիմնական content system-ն է, իսկ frontend-ը replacement presentation layer է։ Պարգևը արագությունն է և ավելի քիչ backend invention։

GraphQL-ը consumers-ին կապում է ձեր թիմի նախագծած schema-ին։ Լավ արված դեպքում այդ schema-ն թաքցնում է Drupal-ը և արտահայտում product domain-ը։ Վատ արված դեպքում այն դառնում է երկրորդ CMS model, որը maintain է արվում code-ում։

REST-ը consumers-ին կապում է custom endpoints-ին։ Դա գերազանց է specific integrations-ի համար և վտանգավոր՝ broad content delivery-ի համար, որովհետև յուրաքանչյուր endpoint դառնում է miniature product՝ իր սեփական maintenance tail-ով։

Ահա այն տարբերակը, որը ես կներկայացնեի executive steering group-ին։

Աղյուսակները մի փոքր sterile են, բայց այս մեկը խնայում է meetings։

Ինչին պետք է հետևեն project managers-ը

API-ի ընտրությունը project plan-ը փոխում է ավելի շատ, քան մարդիկ խոստովանում են։

JSON:API-ի դեպքում critical path-ը content modeling-ն է։ Եթե content model-ը մտածված է, API work-ը կարող է արագ առաջ շարժվել։ Եթե content model-ը chaotic է, frontend development-ը դանդաղում է, որովհետև յուրաքանչյուր query բացահայտում է ևս մեկ editorial compromise։ Senior attention դրեք field naming-ի, reusable paragraph patterns-ի, media relationships-ի, taxonomy-ի և permissions-ի վրա՝ նախքան frontend team-ը սկսի pages-ը wiring անել։

GraphQL-ի դեպքում critical path-ը schema ownership-ն է։ Ո՞վ է design անում schema-ն։ Ո՞վ է review անում breaking changes-ը։ Ո՞վ է գրում resolvers-ը։ Ո՞վ է handles անում performance problems, օրինակ՝ nested queries, որոնք trigger են անում չափազանց շատ backend loads։ Drupal GraphQL module-ը տալիս է tools և extension points, ներառյալ data producer plugins և GraphiQL, բայց չի հեռացնում backend engineering discipline-ի անհրաժեշտությունը։

REST-ի դեպքում critical path-ը contract discipline-ն է։ Յուրաքանչյուր endpoint needs documentation, tests, authentication rules, error semantics և versioning story։ REST-ը cheap է թվում, երբ առաջին endpoint-ն է կառուցվում։ Հինգերորդ endpoint-ը ասում է ճշմարտությունը։

Եվս մեկ բան։ Authentication-ը հաճախ underestimated է։ Drupal JSON:API-ն կապված է Drupal-ի authentication և authorization systems-ի հետ, իսկ REST-ը կարող է օգտագործել authentication providers, ինչպիսիք են Basic Auth-ը և cookies-ը, մինչդեռ OAuth-ը սովորաբար ավելացվում է contributed modules-ի միջոցով։ Lupus Decoupled Drupal documentation-ը մատնանշում է Simple OAuth-ը որպես decoupled setups-ում token-ով API requests authenticate անելու միջոց։

Դա մի թողեք launch-ից առաջ sprint-ին։ Այդ sprint-ը արդեն cursed է։

Performance․ այն վեճը, որը բոլորը պարզեցնում են

GraphQL-ի fans-ը ասում են, որ այն խուսափում է over-fetching-ից։ Ճիշտ է։ JSON:API-ի fans-ը ասում են, որ includes-ը նվազեցնում է round trips-ը։ Նույնպես ճիշտ է։ REST-ի fans-ը ասում են, որ HTTP caching-ը straightforward է։ Կրկին ճիշտ է։

Հիմա տհաճ մասը․ երեքն էլ կարող են արագ լինել, և երեքն էլ կարող են դանդաղ լինել։

GraphQL-ը կարող է նվազեցնել payload size-ը, բայց complex nested queries-ը կարող են պատժել backend-ը, եթե resolvers-ը careless են։ JSON:API-ն կարող է օգտագործել Drupal-ի response caching-ը և includes-ը, բայց payloads-ը կարող են verbose լինել։ REST-ը կարող է neatly map լինել HTTP caching-ին, բայց custom endpoints-ը հաճախ մոռանում են cacheability-ի մասին մինչև performance testing-ը սկսվի։ Fielding-ի REST constraints-ը ներառում է cache, որովհետև cache-ը կարող է նվազեցնել network traffic-ը և latency-ն, բայց stale data-ն և cache invalidation-ը շարունակում են մնալ իրական trade-offs։ Drupal-ի JSON:API documentation-ը explicit կապում է module-ը Drupal response caching-ի հետ, մինչ GraphQL module-ը Drupal.org-ում categorized է Decoupled, Developer tools և Performance բաժիններում։

Այսպիսով՝ ոչ, GraphQL-ը ավտոմատ «performance option» չէ։

Առաջին performance win-ը սովորաբար ավելի լավ content modeling-ն է։ Երկրորդը cache strategy-ն է։ Երրորդը silly client behavior-ից խուսափելն է, օրինակ՝ նույն endpoint-ը տասներկու անգամ կանչելը, որովհետև ոչ ոք չի գրել data access layer։

Գլամուրա՞յին։ Ոչ։ Արդյունավե՞տ։ Այո։

Ուղիղ ընտրության framework

Եթե ես խորհրդատվություն տայի founder-ին կամ CTO-ին, կսկսեի այս հերթականությունից։

Նախ՝ օգտագործեք Drupal-ի սովորական rendered pages-ը, եթե decouple անելու պատճառ չունեք։ Decoupling-ը ավելացնում է hosting-ի, preview-ի, routing-ի, cache-ի, deployment-ի, authentication-ի և debugging-ի բարդություն։ Drupal-ի սեփական decoupled documentation-ը standard Drupal-ը առանձնացնում է decoupled Drupal-ից՝ նշելով, որ layout-ը տեղափոխվում է frontend, իսկ backend-ը expose է անում content-ը APIs-ի միջոցով։ Այդ shift-ը անվճար չէ։

Երկրորդ՝ եթե decoupling եք անում հիմնականում modern frontend-ի համար, սկսեք JSON:API-ից։ Կառուցեք մեկ իրական page, ոչ թե demo։ Ներառեք media, menus կամ navigation, related content, preview needs, authentication՝ եթե required է, և cache behavior։ Դուք ավելի շատ բան կսովորեք մեկ տգեղ page-ից, քան վեց architecture diagrams-ից։

Երրորդ՝ GraphQL-ի անցեք միայն այն ժամանակ, երբ consumer experience-ը արդարացնում է schema work-ը։ Լավ պատճառները ներառում են multiple frontend consumers, Drupal internals-ը թաքցնելու անհրաժեշտություն, complex content graphs կամ aggregation across systems։ Վատ պատճառներն են՝ «մեր frontend developer-ը սիրում է Apollo» և «investor deck-ում գրված է GraphQL»։

Չորրորդ՝ REST օգտագործեք integrations-ի համար, որոնք tight boundaries են պահանջում։ Partner export-ի համար custom endpoint-ը կարող է մաքուր լինել։ Hand-rolled endpoints-ից կազմված ամբողջ content platform-ը կարող է դառնալ չպիտակավորված բանալիներով լի դարակ։

Եվ մաքրեք Drupal model-ը։ Խնդրում եմ։ Ոչ մի API layer չի կարող ամբողջությամբ փրկել content model-ը, որը ոչ ոք չի own անում։

«Future-proof»-ի քաղաքականությունը

Ղեկավարները սիրում են «future-proof» արտահայտությունը։ Ես հասկանում եմ՝ ինչու։ Ոչ ոք չի ուզում հաստատել backend rebuild և տասնութ ամիս անց լսել, որ ընտրված API-ն ընկերությանը փակուղի է մտցրել։

Բայց future-proofing-ը սովորաբար ավելի քիչ է վերաբերում ամենաշքեղ API-ն ընտրելուն և ավելի շատ՝ ընտրելուն, թե որտեղ է թույլատրվում փոփոխություն տեղի ունենալ։

JSON:API-ն ասում է․ «Drupal-ի model-ը contract-ն է»։ Դա ազնիվ է և արագ։

GraphQL-ը ասում է․ «Մեր product schema-ն contract-ն է»։ Դա հզոր է և թանկ։

REST-ը ասում է․ «Այս endpoint-ն է contract-ը»։ Դա ճշգրիտ է և հեշտությամբ բազմապատկվում է maintenance problem-ի։

Չկա universal winner։ Կա միայն համապատասխանություն։

Իմ կողմնակալությունը պարզ է․ սկսեք ամենաքիչ custom բանից, որը կարող է աջակցել product-ին։ Drupal-ում դա սովորաբար նշանակում է JSON:API։ Ավելացրեք GraphQL, երբ կարող եք նշել owner-ին և budget-ը։ Ավելացրեք REST, երբ integration-ը այնքան specific է, որ արժանի է իր սեփական doorway-ին։

Ամենավատ ընտրությունն այն է, որն արվում է fashion-ի համար, որովհետև fashion-ը երբեք չի ներկայանում maintenance-ին։

Փնտրո՞ւմ եք շուկայում Drupal development-ի թիվ 1 ընկերությունը։ Դուք հենց նոր գտաք այն։

Մենք լավագույն Drupal-focused digital agency-ն ենք, ստեղծված արագ, անվտանգ և scalable platforms մատուցելու համար՝ առանց զիջումների։ Նոր builds-ից և redesigns-ից մինչև migrations և long-term support՝ մեր Drupal experts-ը մատուցում են enterprise-grade արդյունքներ boutique-level ուշադրությամբ։

Ամրագրեք զանգ այսօր, և եկեք ձեր Drupal roadmap-ը դարձնենք high-performing իրականություն։