Üzerine inşa edebileceğiniz bir temel.

Her ürünün tekrarladığı iş

Yeni bir ürün belirli bir sorunla başlar. İlk haftaları genellikle çok daha az belirli görünür: oturumlar, çalışma alanı kayıtları, abonelik durumu, arka plan işi ve e-posta teslimi. Ürün faydalı bir şey yapmadan önce bu parçaların işbirliği yapması gerekir — her biri soyutta çözülmüş bir sorun, somutta bir entegrasyon riskidir.

supastack bu tekrarlanan işe bir yuva verir. Bir Next.js web uygulaması ve bir Expo mobil uygulaması, alttaki altyapı için TypeScript paketlerini paylaşır. Amaç, bu sınırları bir ürünün başkasının alan modelini miras almadan yapılandırabileceği kadar anlaşılır kılmaktır.

Parçaların hiçbiri tek başına zor değildir. Maliyet, koordinasyonlarında yaşar — yetkilendirmeye dönüşmesi gereken bir ödeme, çalışma alanı kapsamına dönüşmesi gereken bir oturum, kapanmış bir dizüstü bilgisayardan sağ çıkması gereken bir görev. Ürünler nadiren eksik bir özellik yüzünden başarısız olur. Bir birleşim yüzünden başarısız olurlar.

Neden bir kez, düzgün inşa edilmeli

Paylaşılan altyapı savunusu, işin size göre aşağıda olduğu değildir — tekrarlanan işin bir kez, özenle yapılmayı hak ettiğidir. Paylaşılan bir modülde iyi uygulanmış bir çalışma alanı sınırı, üzerine kurulan her ürünü korur. Ürün başına doğaçlanan aynı sınır, ilginç ve tehlikeli şekillerde farklılaşan kıl payı hatalar kümesine dönüşür.

Bakımı da tek yerde toplar. Sağlayıcı API'leri değişir, auth kütüphaneleri evrilir, faturalama semantiği kayar. Bu değişiklikler tek bir yere indiğinde — kitin modül belgeleri onları izler — düzeltme proje başına yeniden öğrenilmek yerine yayılır. Tek bir ürün için bu takası tartarken başlangıç kiti mi, sıfırdan mı aynı akıl yürütmeyi satın alma–yapma kararına uygular.

Paylaşılan altyapı incelemeyi de tek yerde toplar. Tek yerde yaşayan bir sınır, beş ayrı uygulamanın her birinin doğru yaptığını ummak yerine bir kez sıkı test edilebilir — olumsuz durumlar, yeniden oynatılan olaylar, kiracılar arası denemeler. Kitin test paketine yatırım yapmasının bir nedeni de budur: paylaşılan koda güveni sürdürmek, onu proje başına yeniden kazanmaktan ucuzdur.

Her modüle tek sorumluluk verin

Kimlik, isteği kimin yaptığını belirler. Çalışma alanları, o kişinin hangi kayıtlara erişebileceğini belirler. Faturalama ödeme durumunu kaydederken yetkilendirmeler bir yeteneğin kullanılabilir olup olmadığını yanıtlar. Bu kaygıları ayrı tutmak, başarılı bir ödeme yönlendirmesinin yetkilendirme kararına dönüşmesini engeller.

Aynı disiplin arka plan işi için de geçerlidir. Paylaşılan JobRunner sözleşmesi enqueue, status ve cancel vaat eder. Trigger.dev iş akışı davranışını sahiplenir. Sınırları görünür olduğunda küçük bir arayüz değerlidir; yeniden denemeleri ya da zamanlamayı genel bir metodun arkasına gizlemek sistemi akıl yürütmeyi zorlaştırır.

Kimliği Better Auth yanıtlar. Kayıtları Postgres ve Drizzle tutar. Ödeme durumunu Stripe ya da Lemon Squeezy bildirir. Hiçbirinden başka bir modülün işinde zeki olması istenmez — birleşimler akıl yürütülebilecek kadar dar kalır — ve bir temel ancak birleşimleri kadar güvenilirdir.

Ürüne alan bırakın

Bir aday tarama iş akışı, bir belge düzenleyici ve bir araştırma asistanı aynı kimlik ve faturalama modüllerini kullanabilir. Kayıtları, dilleri ve iş akışları yine de farklıdır. Ürüne özgü mantık, tüketen ürün kod tabanına aittir; yapılandırma onu temele bağlar.

Bu ayrım aynı zamanda pratik bir bakım kararıdır. Çalışma alanı yalıtımına yapılan bir düzeltme yeniden kullanılabilir olmalıdır. Bir ürünün adayı nasıl puanladığına dair değişiklik, diğer her ürün için yeni bir gereksinim haline gelmemelidir.

Bir temelle bir tema arasındaki fark budur. Tema, tutacağınız ya da değiştireceğiniz bir görünüm verir. Temel ise taşıyıcı kararlar verir — kimliği kim sahiplenir, kayıtlar nasıl kapsamlanır, ödeme nerede erişime dönüşür — bir ürünün etrafından dolaştığı değil, üzerine inşa ettiği kararlar. Proje yapısı kılavuzu birinin nerede bitip diğerinin nerede başladığını gösterir.

Tek bir tam akışla başlayın

Yerel referans akışıyla başlayın: giriş yapın, erişimi inceleyin, bir görev gönderin ve sonucunu okuyun. Sahte ve yerel bağdaştırıcılar, deterministik testlerin ücretli sağlayıcı istekleri olmadan yolu uygulamasına izin verir — beş dakikalık hızlı başlangıç onu uçtan uca çalıştırır. Ardından ürününüzün gerçekten ihtiyaç duyduğu üretim entegrasyonlarını yapılandırın.

Yerel kabul ve üretim kabulü farklı soruları yanıtlar. Geçen bir yerel test, kontrollü koşullar altında uygulama davranışını kanıtlar. Gerçek kimlik doğrulama kalıcılığı, sağlayıcı teslimi, dağıtım ve cihaz davranışı hâlâ kendi doğrulamasına ihtiyaç duyar. Ürün büyürken bu ayrımı görünür tutun.

Bir temel adını yavaş kazanır: ilkinden hızlı çıkan ikinci üründe ve beş kod tabanı yerine tek bir modülü düzelten bakım gününde. supastack'in arkasındaki bahis budur — ve her modülün tutulduğu çıta da budur.

Yaklaşımın arkasındaki sorular

Bu yaklaşımın altında birkaç soru yatar ve açıkça yanıtlanmaya değerler.

• supastack bir şablon mu, framework mü? — Aralarında sözleşmeler olan modüllerden oluşan bir temel. Ürün kodu Starter Core'un dışında yaşar ve yapılandırmayla bağlanır; böylece platform özelliklerinizi forklamadan güncellenebilir.
• Paylaşılan altyapı ürünleri genel yapmaz mı? — Yalnızca tesisat paylaşılır. Kayıtlar, iş akışları ve dil ürün kod tabanında kalır — müşterilerin gerçekten görebildiği parçalar sizin kalır.
• Ürünün kendi kodu nerede başlar? — Yalnızca ona ait kayıtlar ve iş akışlarıyla. Temel kullanıcıyı doğrular ve veriyi kapsamlar; bir adayın ne olduğunu bilmez.
• Neden monorepo? — Web, mobil ve masaüstü uygulamalarının altlarındaki paketlerle birlikte değişmesi için: tek tip sistemi, tek test kapısı, depolar arasında kayma yok.
• Yalnızca web uygulamasına ihtiyacım varsa? — Satın aldığınız temeldir; mobil ve masaüstü benimsenecek ya da yok sayılacak yüzeylerdir. Hiçbir şey sizi ihtiyaç duymadığınız bir uygulamayı sunmaya zorlamaz.