Logo
Kavramlar, Fikirler, Stratejiler
Kavramlar, Fikirler, StratejilerÇakışmaları Önlemek için Şemayı Ad Alanlarıyla Ayırmak

Çakışmaları Önlemek için Şemayı Ad Alanlarıyla Ayırmak

WordPress dizininde plugin yayınlayan geliştiriciler, pluginlerini kimin kullanacağını veya sitenin hangi yapılandırma/ortama sahip olacağını — başka hangi pluginlerin kurulu olabileceği dahil — önceden bilmezler. Bu nedenle plugin, çakışmalara karşı hazırlıklı olmalı ve bunları önceden önlemeye çalışmalıdır.

WordPress pluginlerinin çakışmaları önlemesinin yollarından biri PHP ad alanlarıdır. Ad alanları, Composer otomatik yüklemesini etkinleştirmek için PHP Standart Önerisi PSR-4'ü izleyerek PHP topluluğunda yaygın biçimde kullanılmaktadır. PHP paketleri, "vendor-name/package-name" biçiminde satıcı adını içermeli ve ilgili ad alanı PHP kodunda yer almalıdır:

<?php
namespace VendorName\PackageName\ClassName;

Ad alanları, GraphQL bağlamında da anlam ifade edebilir; şemada oluşabilecek aşağıdaki potansiyel çakışmaları önlemek için:

  • Aynı ada sahip iki türün bulunması
  • Aynı tür üzerinde aynı ada sahip iki alanın bulunması
  • Aynı ada sahip iki direktifin bulunması

Ad alanları GraphQL spec'i için talep edilmiştir:

At the moment all GraphQL types share one global namespace. This is also true for all of the fields in mutation/subscription type. It can be a concern for bigger projects which may contain several loosely-coupled parts in a GraphQL schema.

Ancak Lee Byron (Facebook'ta çalışırken GraphQL'in yaratıcılarından biri), spec'e ad alanlarının eklenmesinin gerekli olmadığını düşünmektedir. Bu yorumda, Facebook'un GraphQL şemasındaki binlerce türü çakışma olmadan nasıl yönettiğini açıklamaktadır:

We avoid naming collisions in two ways:

  1. integration tests.

We don't allow any commit to merge into our repository that would result in a broken GraphQL schema. [...]

  1. Common naming patterns.

We have common patterns for naming things which naturally avoid collision problems. [...]

Ancak bu stratejinin Facebook için işe yaraması, WordPress için de işe yarayacağı anlamına gelmez: Facebook, GraphQL şemasına gelen tüm girdileri kontrol ettiğinden, varlıkları adlandırmak için bir prosedür uygulayabilir ve hiçbir çakışma çıkmamasını sağlayabilir. Oysa bir WordPress sitesi büyük ölçüde üçüncü taraf pluginlere dayanır ve bu pluginlerin nasıl üretildiğini kontrol edemez.

Örneğin, bir site WooCommerce ve Easy Digital Downloads pluginlerini kullanıyorsa ve her ikisi de GraphQL şeması için Product adında bir türe sahipse, bir çakışma yaşanacaktır. Site sahibinin tek seçeneği şirketlerden birine ulaşarak kodunu değiştirmesini istemektir. Bu bir önleme değil, düzeltmedir ve güvenilir değildir.

Ad alanları, WordPress site sahiplerine kodlarının her zaman çalışacağı konusunda gönül rahatlığı sağlayabilir. İki türün adı Product ise, site yöneticisi GraphQL şemasında ad alanlarını etkinleştirebilir; bu türler otomatik olarak WooCommerce_Product ve EDD_Product olarak yeniden adlandırılır, böylece çakışma önlenir.

Ek bir avantaj olarak, ad alanları GraphQL şemasını daha zarif kılar: WooCommerce, pluginiyle hiçbir zaman çakışma yaşanmayacağından emin olmak isteseydi, türlerini tür adının kendisinde "ad alanına" almak zorunda kalırdı: WCProduct, WCDownload ve WCPayment (ya da her zaman çalışacağından kesinlikle emin olmak için bunları WooCommerceProduct, WooCommerceDownload ve WooCommercePayment olarak adlandırabilirdi). Ad alanları sayesinde bu türler Product, Download ve Payment gibi daha doğal adlara sahip olabilir.