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)
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)
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ı.
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.
İ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.
4 comments