Bağımsız Web için Bilindik Yöntemlerde Değişiklikler

Ruben Verborgh’un 20 Aralık 2017 tarihli ve “Paradigm shifts for the decentralized Web” orijinal başlıklı yazısının çevirisidir.

Çeviri notu: “decentralized” kelimesi daha ziyade “merkezsizleştirilmiş, merkezi olmayan, gayrimerkezi” anlamına geliyor, işin fikri boyutu ve metindeki kullanım şeklini hesaba katınca uygun yerlerde “bağımsız” şeklinde kullanmakta bir sakınca görmedim. Metinde “bağımsız web” şeklinde kullandığım kalıp “decentralized web” çevirisidir.


Veri ve uygulamalar için ayrı pazarlar türedikçe, web geliştirmenin de yeni bir şekle bürünmesi gerekiyor

Bugün birçok web uygulaması “servislerimi kullanabilmek için verilerini benimle paylaş” görüşünü benimsiyor. Bu görüşü hem teknik açıdan (Verilerin olmadan sana nasıl hizmet verebilirim?) hem de ticari açıdan (Verilerin olmadan nasıl para kazanıp varolabilirim?) savunuyorlar. Webi bağımsızlaştırmak, insanların verilerini istedikleri yerde saklarken ihtiyaç duydukları hizmetleri almaya devam etmesi anlamına geliyor. Bu durum arka planda kapalı devre çalışan veritabanları yerine web üzerindeki açık verileri kaynak olarak kullanmamızı gerektireceğinden, web uygulamalarını geliştirme yöntemlerimizde köklü değişiklikler gerektiriyor. Bu yazıda, bağımsız webin getirdiği üç yöntem değişikliğinden bahsettim ve bağımsızlaştırmanın sadece kendi verimizi yönetmekten çok daha fazlası olduğunu örneklerle açıkladım. Bu, veri ve uygulamalar arasındaki ilişkinin kökten tekrar düşünülmesi, ki — doğru yapılırsa — önümüzdeki yıllarda yaratıcılık ve yenilikçiliği şaha kaldıracak bir şey.

Webi (tekrar) bağımsızlaştırma hareketi genellikle Facebook ve Google gibi teknoloji devlerinin artan gücü karşısında “günümüzün hippi tepkisi” şeklinde küçümseniyor. Bağımsızlıkçılar arasında Davut ve Calut* masalındaki gibi bir görüş hakim olsa da, insanların ve kurumların webin sağladığı devasa potansiyel ve çeşitlilikten vazgeçmeden, verilerini kendi istedikleri gibi saklayabilmeleri gücünü tekrar kazanmasının çok daha fazla avantajı var.

Temelde, bağımsızlaştırma tercihlerle ilgilidir: verimizi nerede sakladığımızı, hangi kısımları için kimlere erişim vereceğimizi, üzerinde hangi hizmetleri çalıştıracağımızı ve bunların ödemelerini nasıl yapacağımızı biz seçmeliyiz. Bugünlerdeyse bunların yerine kesinlikle özelleştiremediğimiz paket çözümler kullanmaya zorlanıyoruz. Örneğin, Facebook bize arkadaşlarımızın paylaşımlarını gösteren bir akış gösteriyor, reklam gösterimlerinden para kazanıyor — ancak bunu sadece her birimiz kişisel bilgilerimizi Facebook’ta tutarsak bize sağlıyor. Burada başkalarının Twitter mesajlarını göremiyoruz (Twitter’daki mesajlarını Facebook profillerine de otomatik kopyalayan bir ayarları yoksa). Bunlar bilindik şeyler, teknik olarak kullandığımız her uygulama bu şekilde çalışıyor. Bu durumun uygunluğu ve etiğini tartışmak yerine, bu yazıda web geliştirmede bağımsızlıkçı yaklaşımın uzun vadeli etkilerinden bahsedeceğim.

Bağımsızlaştırma sadece veri sahipliğiyle ilgili değildir: geliştirme için yeni bir düşünme yöntemi gerektirip veri ve uygulama pazarlarını ayırdığından, yenilikçiliğe ve rekabete teşvik eder. Fotoğraf: ©Damian Hedinger

Bu yazıda, bağımsızlıkçı fikirle web uygulamaları yapmak istiyorsak kendimizi hazırlamamız gereken üç yöntem değişikliğinden bahsedeceğm:

  1. Son kullanıcılar veri sahipleri olur. Bağımsızlıkçı yaklaşımın en bilinen yönüdür: verimizi kendi seçtiğimiz yerlerde saklarız, böylece daha etkili güvenlik ve kontrol sağlarız.
  2. Uygulamalar yönetim ekranlarına dönüşür. Uygulamalar veriden ayrılmış olacağı için kullanacakları veriye erişim ve yönetiminde tek seçenek olmak yerine, istendiğinde aynı işi yapan bir başkası ile değiştirilebilecek yönetim ekranlarına dönüşmektedir.
  3. API arayüzleri sorgulara dönüşür. Veri çok çeşitli arayüzlere dağıtılacağı için, sürdürülebilir uygulamalar kendilerine özel veri talep etmek yerine bildirilen standartlara uygun sorgular göndermelidir.

Bu yöntem değişiklikleri aşağıda detaylıca açıklandı. Mantığı aktarabilmek için sosyal medya siteleri üzerinden örneklemeler yapacağım ama prensipler tüm web uygulamaları için geçerlidir.

Yöntem Değişikliği 1: Son kullanıcılar veri sahiplerine dönüşürler

Bağımsızlaştırmanın temeli şudur: verilerini nerede saklayacaklarını insanlar seçerler. Google ya da Facebook gibi iş yapan birkaç sağlayıcı arasından seçmek yerine, bağımsızlaştırılmış (dağıtılmış, merkeziyetçilikten uzak) bir dünyada, arasından seçebileceğimiz birçok seçenek olacak — ve kendi seçeneğimizi yaratmakta da özgür olacağız. Bu fikir bizi webin asıl amacına geri götürüyor: bir şirketin sahip olduğu tek bir veri akışı yerine herkesin kendi web sitesi veya blogunun olduğu ve fikirlerini burada paylaştığı bir sistem.

Belli bir yere kadar bu seçeneğe zaten sahibiz: başlangıcından beri webin dağınık şekilde barındırılan bağımsız mimarisi, herkese kendi alanına sahip olma imkanını tanıyor. Yine de, tek bir akışın kolaylığından faydalanmayı istiyorken, şu anda bu tek akışı oluşturan merkezi kontrol sistemini istemiyoruz. Bugün sadece merkezi sistemlerde mümkün olanlarla aynı tip servisleri keyifle kullanmaya devam etmek istiyoruz . Yani asıl soru şu: dağınık ve bağımsız veri üzerinde çalışan uygulamalar, merkezi uygulamalarla aynı şekilde çalışabilir mi? Örneğin, arkadaşlarımızın verileri farklı sunucularda bulunuyor olsa bile, tıpkı Facebook’taki gibi bir arkadaş listesi oluşturup sosyal akışı görüntüleyebilir miyiz?

Bu sorunun yanıtı bağımsızlaştırmanın farklı seviyelerine göre değişiklik gösterir:

Kıyaslama doğrusunun bir ucunda, kişisel verileri kendileri için saklayan ve kullanan merkezi çözümler bulunuyor: Twitter ve Facebook milyonlarca ve milyarlarca kullanıcının verisini sadece kendileri için ayrı ayrı saklayan veri merkezleri. Bunun aksine, bağımsızlaştırılmış microblog ağı Mastodon herhangi birine kendi Twitter klonunu kurma imkanı tanıyor. Şu anda 2.400 sunucuda 1,5 milyon kadar kullanıcısı bulunuyor. Birkaç bin insan bir sunucuyu paylaşıyor ve uygulama başka sunuculardaki insanların içeriklerini de okuyabiliyor. Solid ise bunu bir adım daha ileri götürüyor ve her kullanıcı için bir veri bölmesi konseptini tanıtıyor. Bu veri bölmesi bir sunucu üzerinde bulunan ve detaylı yetki yönetimi imkanı olan basit bir veri depolama alanı, böylece herhangi biri tam olarak hangi kişilerin ve uygulamaların, kendi verilerinin hangi kısmına erişebileceğine karar verebiliyor. Uygulamalar birçok veri bölmesinden beslenerek bu sunucuların istemcileri oluyor. Günün sonunda Solid her kullanıcı için birçok veri bölmesinin bulunduğu bir dünya öngörüyor: kişisel bilgiler için evde bir tane, hassas iş dosyaları için ofiste bir tane, öğrenim materyalleri için okulda bir tane, vs. Bu yazıyı böyle yüksek seviyede bir bağımsızlaştırmanın varsayımıyla yazdım. Yukarıdaki kıyaslama doğrusundaki isimlerin sadece öngörülen isimler olduğunu belirtmek isterim: teorik olarak Mastodon ve Solid’i kullanmanın farklı yolları vardır ve bunlardan başka platformlar da bulunmaktadır.

Bugün bir sosyal ağda etkileşimin her bir parçası için bütün veriler merkezi bir yerde saklanıyorken (Facebook gibi), tamamen bağımsızlaştırılmış (merkezsizleştirilmiş) bir sosyal ağda etkileşimin her bir parçası farklı bir veri bölmesinde bulunabilir. Birinin bir makaleyi paylaşarak profesyonel görüşünü belirttiği bu sosyal medya gönderisini ele alalım. Kelime anlamıyla her bir veri parçası farklı bir veri bölmesinde olabilir:

Farklı veri parçalarının farklı veri bölmelerinde saklandığı bir sosyal medya gönderisi

Tamamen bağımsızlıkçı bir yaklaşımda bütün gönderileriniz sizin kendi web siteniz ya da sunucunuzda saklanır. Bir uygulama, takip ettiğim herkesin gönderilerini bu farklı sunuculardan toplar ve benim için bir akışta gösterir. Sizin gönderinizi beğendiğimde, bu “beğeni” benim sunucumda saklanır. Bu işlem benim sunucumun sizin sunucunuza bir bildirim göndermesini sağlar, böylece siz de bu beğeniyi gösterip göstermeyeceğinize karar verirsiniz, — örneğin bu bilginin bir kopyasını tutarak bunu yapabilirsiniz. Herhangi bir şey için yapılan her yorum veya beğeni, bu işlem kaydının okunma, yazma ve silme üzerine ilgili izinleriyle birlikte göndericinin seçtiği bir konumda saklanır.

Her şeyi, kontrol edebileceğimiz bir alanda saklama yöntemi merkeziyetçi yaklaşımla kökten farklılık gösteriyor ve kullanıcılar için birçok faydalı sonucu var. Gizliliği iyileştiriyor, böylece istediğiniz şey hakkında istediğiniz şeyi söyleyebilirsiniz ve bunu Facebook veya herhangi birine açmak zorunda kalmazsınız. Bu durum ifade özgürlüğüne pozitif etki ediyor ve sansürün karşısında duruyor (ilişkili tüm sonuçlar ve tartışmalarıyla birlikte). Esnek erişim kontrolü hayal edilebilen her yolda kullanılabilir: öyle ki kimi beğeni ya da yorumların sadece belli başlı kişilere, gruplara ya da uygulamalara gösterilmesi sağlanabilir — ve bu izinleri istediğiniz zaman değiştirebilirsiniz. İşte gerçek anlamıyla verinin sahibi olmak budur.

Merkezi platformlardan farklı olarak, güven tek bir taraftan sağlanmıyor. Örneğin; gönderimin 124 beğeni aldığını söylediğimde buna inanıyoruz çünkü Facebook böyle söylüyor (açıkçası bundan şüphelenmek için de geçerli bir nedenimiz yok). Merkezsizleştirilmiş bir senaryoda ise bu beğenilerin geldiği her bir bağımsız sunucuya bağlantı verip kaynağın yolunu ortaya çıkararak bunu direkt kanıtlayabilirim. Uygulamam bu bilginin o kişi tarafından dijital olarak imzalanmış bir kopyasını tutabileceği için, bu bağlantılar herhangi bir nedenle çalışmaz hale gelse bile (mesela kişi beğenisini iptal ederse) yine de zamanında bu gönderiyi beğendiğini kanıtlayabilirim. Bu mekanizma merkezi otoriteye dayalı olarak yürümekte olan birçok ağı dönüştürebilir. Örneğin insanların bağlantıları üzerinden bir saygınlık oluşturduğu profesyonel sosyal ağ LinkedIn’i ele alalım. Aslında LinkedIn’i sadece bir adres defteri ile değiştirebiliriz, sizde kayıtlı olan birisi kendi adres defterine sizi kaydetmişse bunu bir bağlantı sayarız.

Verinin tamamen merkezsizleştirilmesindeki asıl mesele ise ölçeklenebilirliktir. Mastodon’a baktığımızda hâlâ birçok kullanıcı için birkaç sunucu olduğunu görüyoruz. Solid’de ise kullanıcı sayısından daha fazla veri bölmesi olması bile mümkün. Sonuç olarak, bağımsızlaştırma dinamik veri kopyalarıyla elden ele dolaşacak, bu da konuyu hassas bir şekilde ele alıp doğru dengelemeyi gerektiriyor; her şeyden önce detaylı erişim kontrolleri de hesaba katılarak veri gizliliği garanti altına alınmalı.

Yöntem Değişikliği 2: Uygulamalar yönetim ekranlarına dönüşür

Bağımsızlaştırma, veri ve uygulama arasındaki sıkı bağı kopararak bir uygulamanın doğal yapısını sorgular ve değiştirir. İkinci yöntem değişikliği yukarıda tartıştığımız birinci yöntem değişikliğinin doğrudan bir sonucu olsa da en az ilki kadar önemli ve kendine has yönleri vardır.

Basitçe, günümüzün popüler merkezi platformlarının birçoğunun rekabet avantajı kendilerine ait veri ambarlarından ve sundukları servisin tamamen bu veriye erişimeye dayanmasından sağlanıyor. Kavramsal olarak konuşursak, Facebook, Twitter ve LinkedIn gibi platformların sunduğu servisaslında hayli basit ve başkaları tarafından kolaylıkla aynıları yapılabilir. Yine de birçok insanın bu platformların servislerinden memnun olmasının en önemli sebebi bunların tuttuğu veri: Facebook etkileşim alıyor çünkü arkadaşlarımızın verisi orada, Twitter dünyadaki bütün tivitlere ve direkt mesajlara sahip ve LinkedIn yaygın profesyonel ağımızı sunuyor. Neticede bu platformlar verileriyle ayrılmaz bir bütün oluyorlar: “Facebook” dediğimizde uygulama ve bu uygulamayı ayakta tutan veriden bahsediyoruz. Günün sonunda neredeyse bütün web uygulamaları sizden sürekli daha fazla veri istiyor, bu durum artık hepsini yönetmemizin mümkün olamayacağı, birbirinin kopyası ve tutarsız profiller oluşmasını sağlıyor. Tabii ki bu durum ciddi gizlilik kaygılarını da beraberinde getiriyor.

Kıyasladığımızda, bağımsızlaştırılmış web uygulamaları veriyi ve uygulamayı birbirinden ayırıyor: veriyi kendi veri bölmenize sadece bir kere girersiniz. Her uygulamada ayrı hesaplar açmak yerine kendi veri bölmeniz üzerinden giriş yapıp, kendinize ait verilerin belirli alanları için istediğiniz uygulamalara okuma veya yazma izni verirsiniz. Böylece web ekosistemi veri+servis şeklinde sunulan paketlerden, değiştirilebilir yönetim ekranları olan uygulamalara evrilir. Bu uygulamaların herbiri sizin kendi veri bölmeniz üzerinden aynı görselleştirme, etkileşim ve işlemleri sunar. Dahası, bu uygulamalar sizin erişim yetkinizin olduğu diğer veri bölmeleriyle de etkileşime geçebilmenizi sağlarlar; arkadaşlarınıza ait veri bölmeleri gibi. Merkezi bir yerde saklanmasından kaçınılarak, uygulamalar veriye sahip olmak yerine izin isterler ve başkaca uygulamalar tarafından yaratılmış verileri de tekrar kullanabilirler.

Bu ekosistemde, Facebook’un haber kaynağı sizin veri bölmenizdeki kişi listenizden beslenen bir ekrana dönüşür, kişi listenizle bu kişilerin kendi veri bölmelerinde kayıtlı son mesajları bir araya getirerek bir akış oluşturur. Bağımsızlaştırılmış LinkedIn ve Doodle için adres defteriniz üzerinde yetki sağlayabilirsiniz, böylece iş arkadaşlarınız toplantı taleplerinden her zaman haberdar olur (çünkü birçok liste yerine tek bir listeniz olacak). Bağımsızlaştırılmış Doodle ve Facebook için takviminize yetki verilebilir, Doodle sadece ne zaman müsait olduğunuzu görüntüleyebilirken Facebook sadece etkinlik ekleyebilir. Bu ekranlardan herhangi birindeki değişiklik doğrudan diğer ekranlara da yansır çünkü hepsi aynı veri kaynağını paylaşır.

Bir diğer önemli nokta ise; veri ve servislerin bu şekilde ayrışması veri ve uygulamalar için birbirinden ayrı pazarlar yaratır. Bir servis sağlama imkanı veri sahipliğine bağımlı olmayacağı için, bu pazarlardan her biri yaratıcılık ve yeniliği canlandırarak kendi rekabet güçleriyle beraber gelir.

Uygulama pazarında kim Facebook’tan daha kullanıcı dostu bir sosyal akış yaparsa ya da LinkedIn’den daha iyi bir profesyonel ağ sunumu sağlarsa sadece servis kaliteleriyle insanları çekebilirler. Dahası, insanlar kendilerine en iyi hizmet veren uygulamayı seçebilir ve bütün uygulamalar kendi veri bölmeniz üzerinde çalışan ekranlar olduğu için uygulamalar arasında istediği zaman geçiş yapabilir. E-posta ve parolanızı tekrar tekrar girmek yerine kendi veri bölmenizle giriş yaparak ilgili veri parçalarına erişim izni verirsiniz — ve bu izni istediğiniz zaman geri çekebilirsiniz. Bununla da kalmıyor; entegrasyon basit hale geliyor: eğer mevcut bir uygulama belli bir özelliği sağlayamıyorsa bu işi yapması için kolayca bir uygulama yazabilirsiniz. Yazdığınız bu uygulama da aynı veriden beslenir ve bu özellik için yeni bir ekran sağlar.

Aynı şekilde veri pazarında da farklı seçenekler ortaya çıkar. İhtiyaçlarınıza bağlı olarak farklı sağlayıcılar tercih edebilirsiniz. Teknik olarak yetkin olanlarımız ise kendi sunucularını barındırmayı tercih edebilir, yüksek ihtimalle buna imkan tanıyan yazılım paketleri çıkacaktır. Kişisel ihtiyaçlariçin insanlar Dropbox’a benzer sağlayıcılar seçebilirler — şimdikinden farklı olarak seçimler uygulama özelliklerine göre değil, sadece veri saklama yeteneklerine göre yapılır. Ek olarak yedekleme ve güvenlik özellikleri sunan daha pahalı planlar bulunabilir. Profesyonel ihtiyaçlar için ise dahili depolamadan bulut tabanlı barındırmaya kadar çok daha geniş bir aralıkta çözümler sunulabilir. Üniversiteler öğrencileri için eğitimleriyle ilgili herhangi bir şey için alan sağlayabilirken hükümetler aynı şeyi vatandaşların resmi belgeleri için yapabilir. Hassas verilerin saklama kurallarına göre düzgün bir şekilde işleneceği, hukuk büroları veya hastaneler için özelleştirilmiş yazılım seçenekleri çıkabilir. Şu anda bu tip sistemler için kullanıcıların uygulamanın tercih ettiği veri saklama seçeneğini doğrudan kabul etmesi gerekiyor.

Sağlıklı bir sistemin anahtarı, uygulamalar ve verinin bağımsızlığından doğan bu iki pazarın bağımsızlığıdır. Şu anda böyle bir ayrışma bulunmadığı için yenilikçi uygulamalar pazara girmekte sıkıntı yaşıyor çünkü ellerinde veri yok — ve mevcut uygulamalar da yenilik getirme endişesine sahip değiller çünkü zaten bütün veriyi ellerinde tutuyorlar. Bu rekabet argümanı içerik ve bağlantıpazarlarını ayrı tutmak için uğraşılan Net Tarafsızlığı tartışmalarına hayli benziyor. Aslında, tıpkı web siteleri ve internet servis sağlayıcıları gibi istediğimizde değiştirebileceğimiz uygulama ve saklama çözümleri getiren tamamen bağımızlıkçı, merkezsizleştirme yaklaşımını, platform tarafsızlığını gerçekleştirmek için bir yol olarak düşünebiliriz.

Yöntem Değişikliği 3: Arayüzler sorgulara dönüşür

Çeviri notu: Burada bahsedilen arayüzler (Interface) uygulama ekranları değil, uygulama katmanları arasında iletişimi sağlamak için kullanılan yazılımsal arayüzlerdir. Wikipedia: Interface (computing)

Üçüncü ve son yöntem değişikliğinde uygulamalar ve veri bölmeleri arasındaki iletişimden bahsedeceğim. Birinci ve ikinci yöntem değişikliklerini baz alarak kendi çıkarımlarımı temsil ediyor.

Günümüz web uygulamaları sunucuyla haberleşebilmek için doğrudan uygulamanın içinde kodlanmış bir dizi özel katman kullanır. Bu iletişim için (genellikle uygulamaya özel yaratılmış) bir arayüz, bir web API’na talepte bulunulur. Eğer uygulamalar birçok veri bölmesi üzerinde çalışan yönetim ekranlarına dönecekse akla gelen önemli bir soru da şu olur: Bu veri bölmeleri uygulamalarla haberleşebilmek için nasıl bir arayüze (iletişim katmanına) sahip olmalıdır?

Tüm bu veri bölmelerinin aynı web API’na sahip olması gerçekçi gözükmüyor (Linked Data PlatformSPARQL, ya da GraphQL gibi). Emsalsiz bir standartlaştırma çabası gerektirmesinin haricinde, zaten böyle bir standartın bütün kullanım senaryolarına yanıt verebilmesi mümkün olmaz. Veri pazarı için de rekabeti hedeflediğimizi hesaba katarsak, farklı tipteki veri bölmelerinin farklı tipte arayüzler (iletişim katmanları) sunmaları beklenir. Buna dayalı olarak, bağımsızlaştırılmış bir webde, uygulamaların ihtiyaç duyduğu veriler birçok veri bölmesine dağıtılmış olacak. Yani bütün veri bölmeleri aynı arayüze sahip olsa bile uygulamaların yine de ilgili talebi doğru veri bölmesine gönderip gelen verileri birleştirmesi gerekecektir.

Bu durum merkezsizleştirilmiş uygulamaların doğrudan sabit bir web API’ı ile haberleşmemesini gerektirir, çünkü bu şekilde sadece belli veri bölmeleriyle haberleşecek şekilde kısıtlanırlar. Eğer arayüzleri değişirse ya da farklı veri bölmelerine de erişmek istersek uygulamaların tekrar programlanması gerekir. Açıkça görülüyor ki uygulama ve veri pazarları arasındaki bu denli sıkı ve kısıtlı bir iletişim yöntemi, sürdürülebilir büyüme ve ölçeklenebilirlik adına ciddi bir darboğaza sebep olur. Belli bölümler için talepleri doğrudan uygulama koduna yazmak yerine, uygulamanın veriyle nasıl bir işlem gerçekleştireceğini tanımlayan üst-seviye bir dil kullanılmalıdır.

Bu nedenle inanıyorum ki merkezsizleştirilmiş web uygulamaları veri bölmelerimizdeki verileri görüntülemek ve güncellemek için sadece bildirimsel sorgular (declarative queries) kullanmalıdır, böylece veri bölmeleri farklı arayüzlere sahip olsa bile uygulama içindeki veri işlemleri hep aynı şekilde ifade edilir. Veri bölmesi arayüzleri ile doğrudan haberleşmek yerine sorgular uygulama tarafındaki bir kütüphane tarafından işlenir, bu kütüphane de bu sorguları bir veya birçok veri bölmesi için sabit HTTP taleplerine çevirir. Bu da şu anlama geliyor; merkezsizleştirilmiş web uygulamaları yatay arayüz yönelimi ya da web API ile direkt iletişim kuran dikey arayüz yerine, uygulama içinde yatay olarak ayrılmış dikey arayüz yönelimine ihtiyaç duyar.

Çeviri notu: Yatay arayüz yönelimi denilen şey, uygulamanın doğrudan servisle değil, servis tarafından oluşturulmuş ve servis tarafında barındırılan bir API aracılığı ile haberleşmesidir. Dikey arayüz etkileşiminde ise uygulama doğrudan servisle etkileşime geçer. Burada bahsedilen “uygulama içinde yatay olarak ayırılmış, dikey arayüz yönelimi” ise uygulamanın kendi içerisinde tutacağı bir kütüphaneye bildirimsel sorgular göndermesini (yatay yönelim), içerideki bu kütüphanenin ise bu sorguları servise uygun hale getirerek direkt servis ile iletişim kurmasını (dikey yönelim) ifade etmektedir. Bağlantı verilen PDF’nin beşinci sayfasında açıklayıcı bir şema bulunuyor.

Bir uygulamanın tüm işlemlerini bildirimsel sorgularla ifade ederek uygulamalar ve sunucu tarafı arayüzler için birbirinden bağımsız gelişimimümkün kılıyoruz. Uygulamanın tasarımı esnasında hızlıca değişen alt-seviye arayüzlerle iletişim kurmak yerine daha yavaş değişime uğrayan yüksek-seviye sorgularla bağlantı kurulur. Çalışma esnasında da istemci tarafındaki sorgu motoru kütüphanesi — ki birçok uygulama aynı kütüphaneyi kullanabilir — ilgili kullanıcının veri bölmesi için oluşturulan sabit web API’ı ile iletişime geçmekle yükümlüdür. Bu aynı zamanda şeffaf bir şekilde veri kopyalanması ve toplanmasına da imkan kılar, çünkü birçok veri bölmesinden veri toplamayı hızlandırmak için buna ihtiyaç duyulur.

Uygulamaların sorgulara bağımlılıklarını düşürmek, geliştirmelerini kolaylaştırmak ve sürdürülebilirliği iyileştirmek karmaşık ve birçok API ile çalışan bir sorgu motoru gerektiriyor. Bu şekilde uyarlanmış birçok motorun rekabet edeceğini ve tek bir API ile haberleşen istemci tarafı kütüphanelerin yerini alacağını öngörüyorum. Bunu ölçeklenebilir bir şekilde gerçekleştirmenin olası bir yönü, tek başına çalışan web API’larını tüm veri bölmeleri için kullanılabilecek API özelliklerine bölmektir. Böylece bu veri bölmeleri, kullanıcılarının seçtiği servis seviyelerine göre farklı yetenekler sunma imkanına sahip olur — Linked Data PlatformSPARQL ve GraphQL (alt setleri), ya da Triple Pattern Fragments gibi. İdeal durumda bir veri bölmesi, uygulama tarafından istenen tüm sorguları desteklemelidir, böylece kütüphane bu sorguları doğrudan bu bölmeye yollayabilir; diğer durumlarda ise kütüphane sorguları birçok talebe bölerek gönderir.

Merkezsizleştirme ve sorgu işlemlerinin birleşimi bizi veriyle etkileşimin farklı bir yoluyla karşı karşıya getirir. Geleneksel web uygulamalarında prosedür tipik olarak şöyledir: “sorguyu gönder — sorgu işleminin tamamlanmasını bekle — gelen tüm yanıtlara göre işlem yap”. Veri bölmelerinin birçok noktaya dağıtıldığı bir seçenekte ise veri toplamanın zaman alacağınıbiliyoruz, yani uygulamalar tüm yanıtların gelmesi için beklemek yerine daha kullanışlı şeyler yapmak için hazırlanmalı. Prosedür “sorguyu gönder — gelen her bir yanıt için işlem yap” haline geliyor, gelen her veri parçasını bir yayın akışı içinde koyuyor. Genel olarak, webin açık bir dünya olduğu hesaba katılarak bütünlük asla hesaba katılmamalı, yani tüm sorguların yanıtlarının sırasıyla ve illa ki döneceği varsayılmamalıdır. Bu, veri ve uygulamalar arasındaki ilişkinin ne kadar kökten değişeceğinin başka bir göstergesidir.

Bir ilerleme yöntemi olarak: bağımsızlaştırma

Yukarıda bahsettiğim her yöntem değişikliği gösteriyor ki webin bağımsızlaştırılması gücün tekrar düzenlenmesi ile ilgili. Öncelikle, insanlar kendi verilerini ve gizliliklerini kontrol etme gücünü elde edecek. İkinci olarak, uygulamalar ve verilerin birbirinden ayrılmasıyla; yeni uygulamalar ve veri çözümleri rekabet gücü kazanacak. Üçüncü olarak, uygulamaların etkileyici gücü, düşük-seviye arayüzler yerine taşınabilir sorgulara bağlı olarak iyileşme gösterir.

Bu blog yazısında açıkladıklarım yavaş ama istikrarlı bir şekilde gerçekleşiyor ve hatta şu anda bulunan protptiplerden ilham alınıyor. Bağımsız editör dokieli ve ek işlevleri en küçük veri parçalarının nasıl birbirinden bağımsız yerlerde saklanabileceğini çok güzel örnekliyor. Yazı MIT’nin Merkezsizleştirilmiş Bilgi Grubunda geçirmek, Solid gibi basit sunucu taraflı veri depolarının, istemci tarafındaki ileri seviye uygulamalar için nasıl imkanlar yarattığını göstermiş oldu. Uygulamalar basit yönetim ekranlarına dönerken her şeyin veri tarafından yönetildiğini ilk defa orada görmüş oldum. Yeni uygulamalar ve birbirinin kopyası veri girişi sayfaları yaratmak yerine, zaten varolan verileri kullanarak günlük ihtiyaçlarımızı çok basit uygulamalarla nasıl karşılayabileceğimizi de Mashlib kanıtlıyor. Ve son olarak, Linked Data Fragments — ve Solid eklentisi — üzerine çalışmalarımız bağımsız sorgulamayı web ölçeğine taşımayı hedefliyor.

Birçok insanın kafasındaki soru ise gerçek dünya senaryolarında merkezsizleştirmenin gerçekçi olup olmadığı. Bir yandan şunu şöyle yanıtlayabilirim; herhangi bir durumda web şu anda olduğundan daha merkezi bir yapıya sahip olamaz. Facebook çoktan birçok kullanıcı için interneti kullanmak için tek yöntem olarak kabullenilmiş durumda. Haliyle tek mantıklı şey daha az merkeziyetçi bir yönde ilerlemek oluyor. Bu öngörüm sadece içgüdülerime dayanmıyor, benzer sonuca varan birçok topluluk gördüm. Diğer yandansa, merkezsizleştirme fikrinin devasa potansiyelini birçok yönden deneyimledim. Bu fikrin sadece coşkulu teknoloji tutkunları tarafından başlatılması gerekmiyor, kimi önemli sektörlerin ihtiyaçları ile beraber büyüyebilirFinanshukuksağlık gibi sektörlerler için bağımsız ve özel veri alanları ilgi çekici olabilir ve bu durum da yüksek güvenlikli veri bölmeleri ve şeffaf erişim yöntemlerine sahip uygulamalar için rekabetçi bir pazar yaratabilir. Dijital bir toplum bakış açısıyla bakılınca; kişisel veri bölmeleri, kişisel verilerimizin belirli bölümlerine sürekli erişim isteyen tarafların sayısının giderek artmasıyla karılaştığımız sorunlara da işaret ediyor. Ayrıca Jim Hendler’ın Marvin Minsky’den yaptığı şu alıntıyı da çok beğendim: “Aynı bilgiyi bize iki kere sormayı bıraktıklarında bilgisayarların zekileşmeye başladıklarını anlayacağız”. Bağımsızlaştırma için doğru bir yaklaşım sergilersek tam olarak bunu sağlamış olacağız.

Ve son soru: tüm bunların ödemelerini kim yapacak? İyi haber şu ki bu konuda da seçme hakkımız olacak. Facebook, Twitter gibi paket çözümler yalnızca reklam bazlı gelir modelleri ve kara lekeli sonuçlar sunarlar. Bağımsızlaştırılmış bir dünyada ise veri bölmelerimiz ve uygulamalarımız için sağlayıcılarımızı birbirinden bağımsız olarak seçebilir ve hangisi için nasıl ödeme yapacağımıza karar verebiliriz. Kötü haber ise bu durum her şeyin “bedava” olmayacağı anlamına geliyor, en azından şu anda öyle gözüküyor. Yine de, kızışan rekabet — iki ayrı pazarda birden — makul fiyatlar sunulmasını sağlayacaktır. Eğer gerçekten bedava seçenekler istiyorsak kişisel verilerimizle ödeme yapmayı hayal edebiliriz. Reklam gösterimleri için kişisel bilgilerimizin belirli parçalarını veririz. Sosyal medya şu anda dolaylı yoldan da olsa tam olarak böyle para kazanıyor. Aradaki temel fark ise şu olacak; verilerimizin hangi kısmının reklamlar için kullanılabileceğine ve hangi kısımlarının kullanılamayacağına biz karar vereceğiz. Bu bir kere daha kanıtlıyor ki; temelinde bağımsızlaştırma verilerimizin kontrolünü tekrar elimize almamızla başlıyor ve yenilikçi web uygulamalarının yeni nesli için bir zemin oluşturuyor.

Ruben Verborgh

Webin tekrar bağımsızlaştırılması üzerine ilham verici sohbetleri ve yol göstericilikleri için Tim Berners-LeeSarven CapadisliDmitri Zagidulin ve Sandro Hawke’a teşekkürler.


Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir