SharePoint Framework 1.23 ve Ötesi: Asıl Mesaj Ne?
Mayıs güncellemesini ilk okuduğumda aklıma şu geldi: SPFx artık sadece “SharePoint’e web part yazalım” seviyesinde değil, bayağı geniş bir Microsoft 365 extensibility omurgasına dönüşmüş durumda. Bu kötü bir haber değil, tam tersine iyi. Ama işin aslı şu ki, bu olgunlaşma beraberinde daha fazla karar noktası getiriyor; yanı mimarı seçimler, güvenlik, bakım yükü. Copilot tarafındaki beklentiler aynı masaya oturuyor (ciddiyim)
Ben SPFx’i ilk kez yıllar önce bir kurumsal portal projesinde denemiştim. O zamanlar hedef çok basitti: birkaç özel web part, biraz list entegrasyonu, biraz da kurum içi duyuru ekranı (en azından benim deneyimim böyle). Sonra iş büyüdü, Teams içine gömülü deneyimler istendi, Viva tarafı açıldı, kullanıcı beklentisi de “hızlı çalışsın ama kurumsal da olsun” noktasına geldi. İşte SPFx’in hikâyesi biraz böyle ilerliyor; küçük başlayıp büyük etkisi olan bir şey.
İşte tam da bu noktada devreye giriyor.
Bu yazıda Mayıs 2026 yol haritasını kendi gözümden okuyacağım. Sadece Microsoft’un ne dediğine bakmayacağım; Türkiye’deki kurumlar için ne anlama geliyor, hangi senaryoda işe yarar, nerede beklediğim kadar parlak değil — bunları da konuşacağız.
SPFx 1.23 neden önemli?
Önce temel yerden başlayayım. SPFx 1.23’ün genel kullanıma açılması tek başına bir sürüm haberi gibi görünse de aslında platformun uzun vadeli sağlığını anlatıyor. Kurumsal tarafta bizler sürüm numarasından çok şu soruya bakıyoruz: Bu değişiklik üretim ortamında rahatlatıyor mu? Bakın şimdi, 1.23’ün verdiği cevap büyük ölçüde evet.
İlginç olan şu ki, List extensibility tarafındaki grouping desteği mesela fena değil, hatta baya iş görüyor. Mesela karmaşık listelerde komutları dümdüz serpiştirmek yerine gruplamak; kullanıcıya “hangi komut ne işe yarıyordu?” sorusunu azaltıyor. Basit gibi dürüyor ama kurumsal kullanıcı için küçük görünen detaylar çoğu zaman adoption’u belirliyor.
Kısa bir not düşeyim buraya. Bu konuyla ilgili Copilot Memory’de Yeni Kontrol Dalgası: Silme, Kapsam ve CLI yazımıza da göz atmanızı tavsiye ederim.
Size bir şey söyleyeyim, Bir de yeni CLI önizlemesi var ki burada ben biraz temkinliyim. Kağıt üstünde çok güzel; daha esnek model, community-driven template yaklaşımı. Çözüm üretme biçiminde yenilenme vadediyor (buna dikkat edin). Ama CLI ekosistemi oturmadan herkesin koşarak geçmesini önermem. Geçen sene Temmuz ayında Logosoft’ta yaptığımız bir müşteri değerlendirmesinde benzer bir araç geçişini aceleye getirmiştik; iki hafta sonra build zincirinde ufak uyumsuzluklar çıktı ve geri adım atmak zorunda kaldık… yanı temkin bazen bedava sigorta oluyor.
Yanı, Platform kalitesi ve güvenlik odağının devam etmesi işe benim en sevdiğim kısım öldü. Çünkü enterprise dünyada “özellik var mı?” kadar “stabil mi?” sorusu da ağır basıyor. Mesela finans ve kamu tarafında çalışan ekiplerde şunu çok gördüm: Yeni yetenek istemeden önce yönetilebilirlik istiyorlar.
Liste komutlarında grup desteği ne kazandırıyor?
Kullanıcı deneyimi açısından bu değişiklik küçük ama etkili. Komutları kategorilere ayırdığınızda ekran kalabalığı azalıyor, yanlış tıklama düşüyor ve eğitim maliyeti hafifliyor.
Küçük ekiplerde bunun getirisi daha sınırlı olabilir; çünkü zaten az sayıda komutla yaşıyorsunuzdur. Büyük organizasyonda işe tablo değişir — onlarca listeyi yöneten ekipler için bu resmen nefes aldırır.
Copilot ve AI tarafı nereye gidiyor?
Neyse, şimdi gelelim en kritik kısma: AI-powered solutions. Microsoft’un mesajı net — SPFx gelecekte sadece klasik UI genişletmesi olmayacak, Copilot ile konuşan deneyimlerin taşıyıcısı hâline gelecek. Bu cümle kulağa büyük geliyor ama pratikte anlamı şu: Kullanıcı artık menü içinde kaybolmadan işini bitirmek isteyecek. Claude Opus 4.8 GitHub Copilot’a Geldi: Peki Gerçekte Ne Değişiyor? yazımızda bu konuya da değinmiştik.
Bence burada iki ayrı dünya var: startup ve enterprise. Startup tarafında geliştirici ekibi küçük olduğu için hızlı prototip çıkarıp kullanıcı tepkisini test etmek mantıklı olurdu muhtemelen boru gibi çalışırdı… Enterprise tarafında işe yetki modeli, veri sınırı ve governance katmanı yüzünden her şey daha ağır ilerler. Yanı aynı teknoloji var ama uygulanış şekli bambaşka (buna dikkat edin) Bu konuyla ilgili Python AI Uygulamalarında Azure App Service: Hız Kazandıran Sessiz Değişim yazımıza da göz atmanızı tavsiye ederim.
Yanı, Ben AZ-500 çalışırken güvenlik tasarımını tekrar tekrar düşünmek zorunda kalmıştım; orada öğrendiğim şey şu öldü: AI eklemek teknik olarak kolaylaşsa bile veri erişimi yanlış kurgulanırsa bütün sistem risk altına girer. SPFx’in Copilot ile birleşmesinde de aynı mesele var — arayüz değil sadece mesele, arkasındaki izinler asıl oyun alanı. Bu konuyla ilgili MCP Apps Copilot Chat’te: İş Akışları Artık Konuşmanın İçinde yazımıza da göz atmanızı tavsiye ederim.
Haziran 2025’te Ankara’da bir kamu müşterisinde yaptığımız workshop’ta ekip bana açıkça şunu sormuştu: “Copilot deneyimini portala gömsek güzel olur ama yanlış bilgi gösterirse ne olacak?” İşte tam burası önemliydi… Güzel özellik. Henüz ham hissi veren yerlerden biri bu alan oluyor; governance katmanı güçlenmeden sihir beklemek hayal kırıklığı yaratabiliyor.
SPFx’in yeni dönemi bana göre üç şeye dayanıyor: modern geliştirme deneyimi, kurumsal ölçekte kontrol edilebilirlik ve Copilot ile doğal entegrasyon.
Küçük ekip mi büyük kurum mu?
Bi saniye — Küçük ekipseniz önce standartlaştırılmış template’lere yaslanın derim. Hız kazanırsınız hem de bakım yükünüz az olur.
Kısa bir not düşeyim buraya. Bu konuyla ilgili TypeScript 7.0 Beta: Hız Değil, Asıl Mesaj Daha Büyük yazımıza da göz atmanızı tavsiye ederim.
İtiraf edeyim, Büyük kurumsanız olay farklı; solution governance olmadan hiçbir AI hikâyesi sağlıklı gitmez. Dağılan yapı sonra sizi yoruyor… bayağı yoruyor.
| Senaryo | Daha uygun yaklaşım | Neden |
|---|---|---|
| Küçük startup | Hazır template + minimum özelleştirme | Daha hızlı teslimat ve düşük bakım yükü |
| Büyük enterprise | Merkezî governance + kontrollü rollout | Güvenlik, uyumluluk ve ölçek yönetimi |
| Pilot proje | Sınırlı geniş çaplı PoC | Amaç davranışı görmek olmalı |
| Tam üretim geçişi | Aşamalı yayılım + telemetry | Sorun çıktığında geri dönüş kolay olur |
Türkiye’de kurumlar bunu nasıl okumalı?
Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo biraz farklı görünüyor çünkü birçok kurum hâlâ hibrit yapıda yaşıyor; bazı sistemler on-prem’de dürüyor, bazıları M365 üzerinde akıyor… Dolayısıyla SPFx yatırımı yaparken yalnızca teknik uygunluğu değil operasyonel gerçekliği de düşünmek gerekiyor.
Maliyet konusu da önemli tabiî. Azure ya da M365 tarafında lisans yükünü TL bazında düşündüğünüzde yönetimin refleksi hemen değişiyor; “bir özellik” diye başlayan talepler bazen bütçe toplantısında sertleşiyor resmen keskinleşiyor diyeyim! O yüzden ben müşterilere her zaman şunu söylüyorum: Eğer kullanım oranınız belirsizse önce dar kapsamlı pilot yapın.
Ne yalan söyleyeyim, Ekim 2024’te İzmir’de bir lojistik firmasında yaptığım danışmanlık görüşmesinde şunu fark etmiştim: Ekip teknolojiye sıcak ama satın alma süreci çekingen ilerliyor du… sebebi basit — fayda görünür olsa bile maliyetin geri dönüşü net isteniyordu sonunda kabul edildiği öldü diyebilirim! Bu yüzden SPFx’in avantajlarını anlatırken yalnızca developer gözlüğü takmak yetmez; business case’i de düzgün kurmak lazım.
Başka türlü proje havada kalır (kendi tecrübem)
Bütçe kısıtlıysa ne yapılır?Eğer bütçe sıkışıksa ilk önerim şudur: doğrudan her şeyi yeniden yazmaya kalkmayın… mevcut listelerden başlayın, command set ile ufak kazanımlar toplayın sonra büyütün.’,
Bu yaklaşım hem ucuz hem de yanlış yatırım riskini azaltır.”””
?>
Nerede zorlanabiliriz?
Şimdi dürüst olayım ; her şey güllük gülistanlık değil. İlk denediğimde CLI önizleme tarafında beklediğim kadar pürüzsüz olmayan birkaç nokta gördüm. Kurulum adımları, template çeşitliliği, topluluk dokümantasyonu… hepsi gelişmeye açık. Yanı evet, iyi yolda ama henüz tam pişmiş değil.
İşin garibi, Ayrıca AI entegrasyonu konusunda da aceleci davranmak hatalı olur. Bir özellik konuşkan diye faydalı olacak diye bir kaide yok ; doğru veri modeli, doğru izin zinciri, doğru fallback mekanizması yoksa son kullanıcı için karışıklık yaratabilir. Ben geçen yıl Kasım ayında bir sağlık kuruluşunda buna benzer hata görmüştüm : demo sırasında müthişti, üretimde işe yanlış bağlamdan dolayı kullanıcı güvenini sarstı. Hayal kırıklığı kısmı tam burasıydı (en azından benim deneyimim böyle)
Peki pratikte nasıl başlamalı?
- Mevcut SharePoint çözümünüzün kullanım verisini çıkarın.
- List View Command Set veya basit web part ile pilot seçin.
- Geliştirme standartlarını tek repo altında toparlayın.
- Copilot entegrasyonunu ancak veri sınırları netse devreye alın. (bu kritik)
// Basit bir SPFx yaklaşımı örneği
const commands = [
{ id: "approve", title: "Onayla" },
{ id: "reject", title: "Reddet" }
];
console.log("Grouped commands ready:", commands);
Bence asıl mesaj ne?
Doğrusu, Benim kanaatim şu : Microsoft burada sadece yeni özellik sunmuyor, platformu gelecek on yıla hazırlıyor. Vesa Juvonen’in güncellemelerinde hep hissettiğim şey budur ; sessiz sakın ilerleyen. Kökten etkileyen adımlar atılıyor. Hani dışarıdan bakınca büyük patlama yokmuş gibi dürüyor, fakat içeride mimarı ciddi biçimde değişiyor.
Bu yüzden blog okuru olarak bizim görevimiz “wow” demek değil yalnızca ; “biz bunu kendi organizasyonumuzda nasıl uygularız ?” sorusunu sormak.
Asıl fark orada çıkıyor.
< div class=”ak-infobox”>
💡? />
Sıkça Sorulan Sorular
SPFx 1.23 ne getiriyor?
SPFx 1.23, platformun stabilite, liste extensibility ve tooling tarafını güçlendiriyor (ki bu çoğu kişinin gözünden kaçıyor). Yanı kurumsal projelerde uzun vadeli bakım açısından gerçekten değerli bir güncelleme (şaşırtıcı ama gerçek). Yeni CLI de bence geleceğe dönük önemli bir sinyal veriyor.
SPFx’i Copilot projelerinde kullanmak mantıklı mı?
Evet, ama şartlı. Açıkçası veri erişimi, izinler ve governance oturmadan direkt yayına çıkmak riskli olabiliyor. Tecrübeme göre ilk aşamada dar etraflı bir PoC yapmak çok daha güvenli bir yol.
Türkiye’de bu çözümler pahalı mı?
Lisans ve operasyon maliyetleri nedeniyle aslında önceden iyi bir planlama yapmak şart. Pilot proje olmadan geniş ölçekli yatırıma girmek çoğu zaman erken bir karar oluyor.
Küçük şirketler için SPFx gerekli mi?
Her zaman şart değil. Hani kullanım senaryosu azsa hazır M365 araçlarıyla başlamak çok daha mantıklı olabiliyor. İhtiyaç büyüdükçe SPFx’e geçmek de mümkün.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Blog Yazısı — SharePoint Framework (SPFx) roadmap update – May 2026
SharePoint Framework Resmî Dokümantasyonu
Microsoft Teams İçin SPFx Örnekleri
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder