Gatsby İşlevleri ve Stripe ile Açık Kaynak Yazılımından Para Kazanın

Bu makalede, açık kaynak projem MDX Embed'i finanse etmeye yardımcı olan güvenli "İstediğiniz kadar öde" katkılarını etkinleştirmek için Gatsby Functions ve Stripe API'yi nasıl kullandığımı açıklayacağım.

Not : MDX Embed, YouTube videoları, Tweetler, Instagram gönderileri, Egghead dersleri, Spotify, TikTok ve daha pek çok popüler üçüncü taraf medya içeriğini doğrudan .mdx - içe aktarma gerekmez.

Gatsby Sunucusuz İşlevler

Gatsby İşlevleri, bir sunucuyu sürdürme zahmetine girmeden sunucu tarafı kodu yazmanın ve kullanmanın bir yolunu sağladığı için ön uç geliştiriciler için yepyeni bir dünyanın kapılarını açar. Sunucusuz İşlevler için kullanımlar, ConvertKit ile Bülten kayıtlarına, SendGrid kullanarak bir e-posta göndermeye, Fauna gibi bir veritabanında veri kaydetmeye veya bu durumda, Stripe kullanarak güvenli ödemeleri kabul etmeye kadar uzanır - liste açıkçası sonsuzdur!

Yukarıda belirtilenler gibi üçüncü taraf hizmetler yalnızca sunucu tarafından gönderilen istekleri kabul edecektir. Bunun birkaç nedeni vardır, ancak güvenli veya özel anahtarların kullanılması genellikle bunlardan biridir. Bu anahtarları sunucu tarafında kullanmak, istemciye (tarayıcıya) maruz kalmadıkları ve kötüye kullanılamayacakları anlamına gelir ve burada Gatsby'nin Sunucusuz İşlevleri yardımcı olabilir.

Gatsby, Sunucusuz İşlevler için sayfalarda olduğu gibi aynı mantıksal yaklaşımı sağlar. Örneğin, web sitesi sayfaları src/pages içinde bulunur ve Sunucusuz İşlevler src/api içinde bulunur.

Doğal olarak, bundan biraz daha fazlası var ama Gatsby'nin geliştirici deneyimi hem mantıklı hem de tutarlı ve ben şahsen buna bayılıyorum!

Aynı Köken İşlevleri

Sunucusuz İşlevler ile çalışırken on seferden dokuzu, bunları kullanılmaları gerektiği gibi kullanacaksınız, Örneğin, web siteniz kendi işlevlerini kullanıyor. Bu kullanıma kısaca Same Origin Functions veya SOF'lar diyorum. Bu senaryoda, hem Ön Uç hem de API aynı kaynağa, örneğin www.my-website.com ve www.my-website.com/api'ye dağıtılır ve ikisi arasındaki iletişim hem sorunsuz hem de elbette , çok hızlı!

Bunun neye benzediğini göstermeye yardımcı olacak bir diyagram:

Çapraz Kaynak İşlevleri

Bununla birlikte, “Çapraz Kaynak İşlevleri” (veya kısaca COF'ler) olarak adlandırdığım şeye ihtiyaç duyduğum yerde karşılaştığım en az iki senaryo var. COF'lere ihtiyaç duyduğum iki senaryo aşağıdaki gibidir:

1. Sunucu tarafı yeteneklere ihtiyacım var ama kaynak web sitesi Sunucusuz İşlevleri çalıştıramıyor.
2. Sunucusuz İşlev, birden fazla kaynak tarafından kullanılır.

Not : Sunucusuz İşlevler yazmanın tek yolu Gatsby'yi kullanmak değil, birazdan bununla ilgili daha fazla bilgi.

Bu yaklaşımı ilk olarak Kasım 2020'de Gatsby Functions'ın piyasaya sürülmesinden önce denedim ve Twitter API'si ve Gatsby blogum ve ticari portföyümle sunucudan sunucuya iletişim sağlamak için Netlify Functions'ı kullandım. Bu yaklaşımı buradan okuyabilirsiniz: Gatsby blogunuz için bir CMS olarak Netlify Functions ve Twitter API v2'yi kullanın.

Gatsby Functions'ın Haziran 2021'de piyasaya sürülmesinden sonra, Gatsby Functions ile çalışmak için yukarıdakileri yeniden düzenledim ve işte nasıl ve neden yaptığımla ilgili biraz daha bilgi: Gatsby Functions'ı soyutlanmış bir API olarak kullanma.

İşte genel yaklaşımı daha iyi göstermek için bir diyagram.

Yukarıdaki şemada, website-1.com Gatsby ile oluşturulmuştur ve Sunucusuz İşlevleri kullanmış olabilir (ancak kullanmaz) ve website-2.com , Sunucusuz İşlev yetenekleri olmayan bir şey kullanılarak oluşturulmuştur.

Not : Her iki durumda da, her ikisinin de aynı üçüncü taraf hizmeti kullanması gerekir, bu nedenle bu işlevi bağımsız bir API'ye soyutlamak mantıklıdır.

Örnek bağımsız API ( my-api.com ) aynı zamanda bir Gatsby sitesidir ve Sunucusuz İşlev özelliklerine sahiptir, ancak daha da önemlisi, diğer kaynaklardan gelen web sitelerinin Sunucusuz İşlevlerini kullanmasına izin verir.

Ne düşündüğünüzü biliyorum: CORS! Peki, sıkı otur. Bunu birazdan ele alacağım.

MDX Yerleştirmesinden Para Kazanma

MDX Embed ile kendimi içinde bulduğum durum buydu. Bu proje için dokümantasyon web sitesi Storybook kullanılarak oluşturulmuştur. Storybook'un sunucusuz yetenekleri yok ama gerçekten sunucudan sunucuya iletişime ihtiyacım vardı. Çözümüm? Paulie API adında bağımsız bir API oluşturdum.

Paulie API'si

Paulie API (yukarıda bahsedilen örnek bağımsız API gibi) farklı kaynaklardan gelen web sitelerinden gelen istekleri kabul edebilir ve biri Stripe olan bir dizi farklı üçüncü taraf hizmetine bağlanabilir.

MDX Embed'den Stripe ödemelerini etkinleştirmek için, Paulie API'sinde, ilgili bilgileri MDX Embed'den kendi Sunucusuz İşlevi aracılığıyla ve bir "ödeme" oluşturmak için Stripe API'sine iletebilen bir api/make-stripe-payment uç noktası oluşturdum. src kodunu burada görebilirsiniz.

Bir ödeme başarıyla oluşturulduktan sonra, Stripe API bir URL döndürür. Bu URL, tarayıcıda “müşterilerin” ödeme ayrıntılarını bir Stripe web sayfasına güvenli bir şekilde girebilecekleri yeni bir pencere açan MDX Embed'e geri gönderilir… ve patlama! Ödeme alırsınız!

İşte bunun nasıl çalıştığını daha iyi gösteren bir diyagram:

Bu yaklaşım, https://mdx-embed.com'un https://paulieapi.gatsbyjs.io'ya istek gönderdiği ve bunun da sunucudan sunucuya iletişim kullanarak Stripe API'sine bağlandığı yukarıda belirtilenle aynıdır. Ancak çok daha ileri gitmeden önce, neden react-stripe-js kullanmadığımı açıklamaya değer.

react-stripe-js

react-stripe-js , React projenizde Stripe çıkışları ve öğeleri oluşturmanıza olanak tanıyan bir istemci tarafı (tarayıcı) araç takımıdır. tepki-stripe-js ile sunucu tarafı iletişime ihtiyaç duymadan ödemeleri güvenli bir şekilde kabul etmek için bir yöntem oluşturabilirsiniz, ancak… ve bir ama var. “İstediğini öde” katkılarını uygulamak istedim. Açıklamama izin ver.

İşte Stripe panomda kurduğum MDX Embed “ürününün” ekran görüntüsü. Fiyatın 1,00 $ olduğuna dikkat edin.

Ödemeleri etkinleştirmek için tepki-stripe-js kullansaydım, tüm "müşterilerden" aynı tutarı ödemeleri istenirdi. Bu durumda, sadece 1,00 dolar ve faturaları ödemeyecek, değil mi?

"İstediğini öde"yi etkinleştirmek için (örneğin, bir "müşteri" tarafından seçilen nominal bir miktar), biraz daha derine inmeniz ve sunucular arası iletişimi kullanmalı ve bu tutarı özel bir HTTP isteği kullanarak Stripe API'sine göndermelisiniz. Burada bir Gatsby İşlevi kullanıyorum ve daha sonra "ödeme" deneyimini oluşturmak ve Stripe gösterge tablomda tanımlanan fiyatın üzerine yazmak için kullanılacak dinamik bir değer giriyorum.

MDX Embed'de, "müşterilerin" önceden tanımlanmış bir miktar ödemek yerine bir miktar belirlemesine olanak tanıyan bir HTML <input type="number" /> ekledim - keşke tüm e-ticaret böyle olsaydı!

İşte MDX Embed, Paulie API ve Stripe API'nin birlikte nasıl çalıştığını gösteren küçük bir video:

Girdi değerini MDX Embed'den Paulie API'sine geçirerek, bu da Stripe API'sine bağlanır ve “dinamik” bir ödeme oluşturabiliyorum.

Not : Bu, artık “müşterilerin” projenin kendileri için ne kadar değerli olduğuna karar verebilecekleri ve katkıda bulunmak için uygun bir miktar belirleyebilecekleri anlamına geliyor.

Bu noktada, muhteşem Yaz Fonksiyonları kursu sırasında bana bu yaklaşımı ilk kez gösteren Benedicte Raae'den bahsetmek istiyorum. Kraliçe Raae Kodlarını ziyaret ederek daha fazlasını öğrenebilirsiniz. ( Teşekkürler Benedict, sen en iyisisin! )

CORS Hakkında Konuşalım

Varsayılan olarak, Gatsby Sunucusuz İşlevler, Ön Uç ve API aynı Köken'e dağıtıldığından CORS tarafından engellenmeyecektir. Bununla birlikte, Cross-Origin Functions geliştirirken API'nizi, kendisininkinden farklı kaynaklardan gelen istekleri kabul edecek şekilde yapılandırmanız gerekir.

api/make-stripe-payment uç noktasında CORS'u nasıl ele aldığımı gösteren bir kod parçacığı:

 // src/api/make-stripe-payment const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY) import Cors from 'cors' const allowedOrigins = [ 'https://www.mdx-embed.com', 'https://paulie.dev', ] const cors = Cors({ origin: (origin, callback) => { if (allowedOrigins.includes(origin)) { callback(null, true) } else { callback(new Error()) } }, }) const runCorsMiddleware = (req, res) => { return new Promise((resolve, reject) => { cors(req, res, (result) => { if (result instanceof Error) { return reject(result) } return resolve(result) }) }) } export default async function handler(req, res) { const { success_url, cancel_url, amount, product } = req.body try { await runCorsMiddleware(req, res) try { const session = await stripe.checkout.sessions.create({ success_url: success_url, cancel_url: cancel_url, payment_method_types: ['card'], line_items: [ { quantity: 1, price_data: { unit_amount: amount * 100, currency: 'usd', product: product, }, }, ], mode: 'payment', }) res.status(200).json({ message: ' Stripe checkout created ok', url: session.url }) } catch (error) { res.status(500).json({ message: ' Stripe checkout error' }) } } catch (error) { res.status(403).json({ message: ' Request blocked by CORS' }) } }

Yukarıdaki kod parçacığında, bir dizi allowedOrigins tanımladığımı görebilmeniz gerekir, bunlar, bu bitiş noktasını kullanmasına izin verilen tek kaynaktır. Başka herhangi bir kaynaktan gelen istekler, bir 403 durum kodu ve Request blocked by CORS mesajı alacaktır.

Bu işlev ayrıca bir dizi gövde parametresini kabul eder, bunlardan biri "müşterinin" ödemeye karar verdiği amount , bu MDX Embed sitesindeki HTML girişinden gelen değerdir. Ayrıca product parametresini de fark edeceksiniz; bu, Stripe kontrol panelimde tanımlanan ürün kimliği ve Stripe API'nin doğru "ödeme" URL'sini nasıl oluşturduğudur. Bu değeri, işlevde kodlamak yerine bir gövde parametresi olarak iletmek, bu bitiş noktasını diğer Stripe ürünleri için yeniden kullanmama izin veriyor.

Suyu Sıkmaya Değer mi?

Neden bu rotaya gitmeye karar verdiğime dair yol boyunca birkaç şeyden bahsetmiştim. Sonuçta, Sunucusuz İşlevleri kullanmanın daha karmaşık bir yolu gibi görünebilir, ancak nedenlerim var ve buna değer olduğunu düşünüyorum. İşte neden.

Paulie API, hem Cross-Origin API hem de bir dokümantasyon sitesidir. Doğal olarak, bir API yazacaksanız bunun belgelenmesi gerekiyor, değil mi?

Burası, API'mi güçlendirmek için Gatsby'yi kullanmak benim lehime çalışıyor çünkü Paulie API, Sunucusuz yeteneklerle birlikte bir Gatsby web sitesidir ve aslında bir web sitesi olduğu için onu içerikle doldurabilir ve güzel görünmesini sağlayabilirim, ama bekleyin dahası var …

Not: Paulie API aynı zamanda etkileşimli bir API oyun alanıdır!

Her işlevin bir Run in browser bağlantısı vardır. Bu sizi sitede işlevle etkileşime girebileceğiniz bir sayfaya götürür. Hem işlevi geliştirirken yararlı bir test alanı hem de işlevin nasıl çalıştığını göstermenin kolay bir yolu olarak hizmet ediyor, dokümanlar iyidir, etkileşimli dokümanlar daha iyidir!

Bu API'yi diğer web sitelerim için benzer sunucu tarafı işlevselliği sağlamak için de kullanıyorum. Hangi sitelerimin hangi işlevleri kullandığını belgelediğim Hakkında sayfasına bir göz atın ve işte bunların şu anda nasıl bir araya geldiğini gösteren bir şema.

Yukarıdaki şemadan https://paulie.dev'in Stripe uç noktasını da kullandığını görmelisiniz. “İstediğini öde” işlevini etkinleştirmek için MDX Embed ile aynı yaklaşımı kullandım. Bu küçük bir şey, ancak make-stripe-payment bitiş noktası zaten yazılı olduğu ve çalıştığı için, onu yeniden kullanabilir ve bu işlevi tekrar etmekten kaçınabilirim.

https://paulie.dev web sitesinde ayrıca, Fauna'ya kullanıcı tepkilerini göndermek ve Bülten kayıtlarını yakalamak için kullandığım kendi Gatsby Sunucusuz İşlevleri de var. Bu işlevsellik bu siteye özgüdür, bu yüzden bunu henüz soyutlamadım. Ancak, https://www.pauliescanlon.io adresinde haber bülteni kayıtlarını isteseydim, bu, işlevi Paulie API'sine geçirdiğim nokta olurdu.

Soyutlama

Bu, Sunucusuz İşlevlerinizi soyutlamak için geriye doğru bir adım gibi görünebilir. Sonuçta, sunucusuz duruma geçmenin en havalı yanlarından biri, hem ön hem de arka uç kodunuzun aynı yerde yayında olmasıdır. Gösterdiğim gibi, soyutlamanın mantıklı olduğu zamanlar vardır - benim için zaten.

Bu yaklaşımı kullanmaktan kesinlikle faydalanıyorum ve bir dizi kendi web siteme daha fazla işlevsellik sağlamak için API'mi daha da geliştirmeyi planlıyorum, ancak açık kaynaktan para kazanmak ilginizi çekiyorsa ve siteniz Gatsby kullanılarak oluşturulmadıysa , bu yaklaşım aradığınız cevap olabilir.

Gatsby Functions'ı kullanmaya başlamak ister misiniz? Başlamak için Gatsby Functions belgelerine göz atın!

Daha fazla okuma

Sunucusuz İşlevler hakkında daha fazla bilgi edinmek istiyorsanız şunları öneririm:

• Swizec Teller'ın kitabı, “Ön Uç Mühendisleri İçin Sunucusuz El Kitabı”
• Benedict'in Yaz Fonksiyonları kursu
• …ve tabii ki Gatsby belgeleri

FuncJam

17 Ağustos'tan 30 Eylül'e kadar, Gatsby halkı, kesinlikle kazanılacak mega ödüllerin olduğu bir topluluk yarışması düzenliyor. Hala zaman varsa, FuncJam'e gidin ve katılın. Ayrıca, bu blog gönderisinin Bayt boyutu bölümüne bakın; faydalı videolar ve bir dizi örnek fonksiyona bağlantılar içerir.

Okuduğunuz için teşekkürler ve bu makalede bahsedilen herhangi bir şeyi tartışmak isterseniz, aşağıya bir yorum bırakın veya beni Twitter'da bulun.