Sıfırdan bir grup web uygulaması oluşturmak üzereyim. (Genel bakış için http://50pop.com/code adresine bakın .) Onlara birçok farklı istemciden erişebilmelerini istiyorum: ön uç web siteleri, akıllı telefon uygulamaları, arka uç web hizmetleri, vb. Her biri için JSON REST API.

Ayrıca, arka uç üzerinde çalışmayı tercih ediyorum, bu yüzden sadece API'ya odaklanmamı ve bir web sitesi, iPhone, Android veya başka bir uygulama olsun, ön uç kullanıcı arayüzü yapmak için başka birini işe almayı hayal ediyorum.

Lütfen hangi yaklaşımı benim izlemem gerektiğine karar vermeme yardımcı olun:

RAYLARDA BİRLİKTE

Çok standart bir Rails web uygulaması yapın. Denetleyicide, JSON veya HTML sunmak için answer_with anahtarını yapın. JSON yanıtı benim API'm.

Pro: Çok sayıda emsal. Büyük standartlar ve işleri bu şekilde yapmanın birçok örneği.

Con: API'nın web uygulamasıyla aynı olmasını istemiyorum. Anahtar yaklaşımıyla if / then response_w beğenmeyin. Çok farklı iki şeyi karıştırmak (UI + API).

REST SUNUCUSU + JAVASCRIPT-AĞIR MÜŞTERİ

Yalnızca JSON REST API sunucusu yapın. API'da doğrudan erişmek ve şablonları tarayıcıda görüntülemek için istemci tarafı JavaScript için Backbone veya Ember.js'yi kullanın.

Pro: API ve istemcinin ayrılmasını seviyorum. Akıllı insanlar bunun yolunun olduğunu söylüyor. Teoride harika. Modern ve heyecan verici görünüyor.

Con: Pek emsal değil. Bunun pek bir örneği iyi yapılmadı. Herkese açık örnekler (twitter.com) halsiz ve hatta bu yaklaşımdan uzaklaşıyor.

REST SUNUCU + SUNUCU-YAN HTML MÜŞTERİ

Yalnızca JSON REST API sunucusu yapın. Yalnızca REST API'sine erişen temel bir HTML web sitesi istemcisi yapın. Daha az istemci tarafı JavaScript.

Pro: API ve istemcinin ayrılmasını seviyorum. Ancak düz HTML5 sunmak oldukça kusursuzdur ve istemci yoğun değildir.

Con: Pek emsal değil. Bunun pek bir örneği iyi yapılmadı. Çerçeveler de bunu desteklemiyor. Nasıl yaklaşacağından emin değilim.

Özellikle sadece teoride değil deneyimlerden tavsiye almak.

At sınırsız , biz seçenek # 2 ile derin gittin ve binlerce öğrenci için dışarı yuvarlandı. Sunucumuz bir JSON REST API'sidir (Scala + MongoDB) ve tüm müşteri kodumuz doğrudan CloudFront'tan sunulur (yani: www.boundless.com yalnızca CloudFront için bir takma addır).

Artıları:

• Üstün / verici
• Paranız için çok fazla patlama: API size kendi web istemciniz, mobil istemcileriniz, 3. taraf erişimi vb.
• son derece hızlı site yükleme / sayfa geçişleri

Eksileri:

• Çok daha fazla çalışma olmadan SEO dostu / hazır değil.
• % 70 javascript ve bunun anlamı olan bir site deneyiminin gerçekliği ile başa çıkmaya hazır birinci sınıf web ön uç halk gerektirir.

Bunun tüm web uygulamalarının geleceği olduğunu düşünüyorum.

Web ön uç millet için bazı düşünceler (bu yeni mimari / meydan okuma bu mimarinin verildiği yerdir):

• CoffeeScript. Yüksek kaliteli kod üretmek çok daha kolay.
• Omurga. Mantığınızı ve aktif topluluğunuzu düzenlemenin harika bir yolu.
• HAMLC. Haml + CoffeeScript şablonları => JS.
• SUKDÖ

'Spar' (Tek Sayfalı Uygulama Rocketship) adlı ön uç geliştirmemiz için, Rails'in tek sayfalık uygulama geliştirme için ayarlanmış varlık pipeline'ı olan bir koşum takımı geliştirdik. Önümüzdeki birkaç hafta içinde github sayfamızın yanı sıra, nasıl kullanılacağını ve genel mimariyi daha ayrıntılı olarak açıklayan bir blog yazısı ile birlikte açık kaynak kullanacağız.

GÜNCELLEME:

İnsanların Omurga ile ilgili endişeleri ile ilgili olarak, bence aşırı puan. Omurga, derin bir çerçeveden çok daha örgütsel bir ilkedir. Twitter'ın sitesi, milyonlarca kullanıcı ve eski tarayıcıdaki her köşe vakasını kapsayan dev bir Javascript canavarıdır. görüldüğü gibi, Twitter tuhaf biri. JS aracılığıyla çok iyi ücret alan etkileyici etkileyici uygulamalar var.

Ve mimari seçiminiz tamamen hedeflerinize bağlıdır. Birden fazla müşteriyi desteklemenin en hızlı yolunu arıyorsanız ve iyi ön uç yeteneğine erişiminiz varsa, bağımsız bir API'ya yatırım yapmak harika bir yoldur.

Çok iyi sordum. +1. Elbette, bu benim için gelecekte faydalı bir referans. Ayrıca @Aaron ve diğerleri tartışmaya değer kattı. Ruby gibi, bu soru diğer programlama ortamları için de aynı derecede geçerlidir.

İlk iki seçeneği kullandım. Birincisi çok sayıda uygulama için, ikincisi açık kaynak projem Cowoop için

seçenek 1

Bu şüphesiz en popüler olanıdır. Ama uygulamanın çok http-ish olduğunu düşünüyorum. Her API'nin ilk kodu istek nesnesiyle ilgilenir. Yani API kodu saf yakut / python / diğer dil kodundan daha fazlasıdır.

seçenek 2

Bunu hep sevdim.

Bu seçenek aynı zamanda HTML'nin sunucuda çalışma zamanı oluşturulmadığı anlamına gelir. Seçenek 2, seçenek 3'ten farklıdır. Ancak derleme komut dosyası kullanılarak statik html olarak derlenirler. İstemci tarafına yüklendiğinde, bu HTML API sunucusunu JS API istemcisi olarak çağırır.

• Endişelerin ayrılması büyük avantajdır. Ve çok beğenmek (ve benim) arka uç uzmanları için arka uç API'leri uygulamak, çerçeve / http istek kodu hakkında endişelenmeden normal dil kodu gibi kolayca test edin.

• Bu gerçekten ön uç tarafında göründüğü kadar zor değil. API çağrıları ve sonuç verileri (çoğunlukla json) müşteri tarafı şablonunuz veya MVC'niz tarafından kullanılabilir.

• Daha az sunucu tarafı işleme. Bu, emtia donanımı / daha ucuz sunucu için gidebileceğiniz anlamına gelir.

• Katmanları bağımsız olarak test etmek daha kolay, API dokümanları oluşturmak daha kolay.

Bazı dezavantajları var.

• Birçok geliştirici, bunu fazla tasarlanmış ve anlaşılması zor buluyor. Yani mimarlık eleştirilebilir.

• i18n / l10n zor. HTML temelde oluşturulmuş oluşturma süresi statik olduğundan, desteklenen her dil için birden çok derleme gerekir (bu mutlaka kötü bir şey değildir). Ancak bununla birlikte l10n / i18n civarında köşe vakalarınız olabilir ve dikkatli olmanız gerekir.

Seçenek 3

Bu durumda arka uç kodlaması ikinci seçenekle aynı olmalıdır. Seçenek 2'nin çoğu noktası burada da geçerlidir.

Web sayfaları sunucu tarafı şablonları kullanılarak çalışma zamanına dönüştürülür. Bu, daha yerleşik / kabul edilmiş tekniklerle i18n / l10n'yi çok daha kolay hale getirir. Kullanıcı, dil, para birimi vb. Gibi sayfa oluşturma için gerekli bazı temel içerik için daha az http çağrısı olabilir. Dolayısıyla sunucu tarafı işleme, oluşturma ile artırılır, ancak muhtemelen API sunucusuna daha az http çağrısı ile telafi edilir.

Artık sayfalar sunucuda sunucu haline getirildiğine göre, ön uç artık programlama ortamıyla daha bağlantılı. Bu, birçok uygulama için bile dikkate alınmayabilir.

Twitter davası

Anladığım kadarıyla, Twitter ilk sayfa görüntülemelerini sunucuda yapabilir, ancak sayfa güncellemeleri için hala DOM'yi işlemek için bazı API çağrıları ve istemci tarafı şablonları vardır. Yani bu durumda, biraz ek yük ve karmaşıklık katan bakımı için çift şablonunuz var. Twitter'ın aksine herkes bu seçeneği karşılayamaz.

Projemiz Stack

Python kullanıyorum. REST yerine JsonRPC 2.0 kullanıyorum. Çeşitli nedenlerle JsonRPC fikrini sevmeme rağmen REST'i öneriyorum. Aşağıdaki kütüphaneleri kullanıyorum. 2/3 seçeneğini göz önünde bulunduran biri bunu faydalı bulabilir.

• API Sunucusu: Python Hızlı bir web mikro çerçevesi - Flask
• Ön uç sunucusu: Nginx
• İstemci tarafı MVC: Knockout.js
• Diğer ilgili araçlar / kütüphaneler:
  • jQuery
  • Para birimi için Accounting.js
  • Webshim : Çapraz tarayıcı çoklu dolgusu
  • yönetmen : İstemci tarafı yönlendirme
  • sphc : HTML oluşturma

Sonuç ve tavsiyem

Seçenek 3 !.

Tüm bunlar, 2. seçeneği başarıyla kullandım ama şimdi biraz basitlik için 3. seçeneğe doğru eğildiğimi söyledi. Derleme komut dosyası ile statik HTML sayfaları oluşturmak ve onlara statik sayfalar sunmak konusunda uzmanlaşmış ultra hızlı sunucudan biriyle sunmak çok caziptir (Seçenek 2).

Gaug.es'yi oluştururken # 2'yi seçtik. API (ruby, sinatra, vb.) Üzerinde çalıştım ve iş ortağım Steve Smith, ön uç (javascript istemcisi) üzerinde çalıştı.

Artıları:

1. Paralel olarak hızlı hareket edin. Steve'in önünde çalışsaydım, yeni özellikler için API oluşturmaya devam edebilirdim. Önümde çalışsaydı, API'yi kolayca taklit edebilir ve kullanıcı arayüzünü oluşturabilirdi.

2. Ücretsiz API. Uygulamanızdaki verilere açık erişim hızlı bir şekilde standart bir özellik haline geliyor. Sıfırdan bir API ile başlarsanız, bunu ücretsiz olarak alırsınız.

3. Temiz ayırma. Uygulamanızı müşterileri olan bir API olarak düşünmek daha iyidir. Elbette, ilk ve en önemli istemci bir web olabilir, ancak diğer istemcileri (iPhone, Android) kolayca oluşturmanızı sağlar.

Eksileri:

1. Geriye Dönük Uyumluluk. Bu, doğrudan sorunuzdan daha çok bir API ile ilgilidir, ancak API'niz orada olduğunda, onu kıramazsınız veya tüm müşterilerinizi ikiye böldünüz. Bu, daha yavaş hareket etmeniz gerektiği anlamına gelmez, ancak aynı anda iki şeyi çalıştırmanız gerektiği anlamına gelir. API veya yeni alanlara ekleme yapmak iyidir, ancak sürüm oluşturma olmadan değiştirme / kaldırma işlemi yapılmamalıdır.

Artık eksilerini düşünemiyorum.

Sonuç: Bir API yayınlamayı planlıyorsanız, API + JS istemcisi gitmenin yoludur.

Not: API'nızı yayınlamadan önce tam olarak dokümante etmenizi de tavsiye ederim. Gaug.es API'sını belgeleme süreci gerçekten bize

http://get.gaug.es/documentation/api/

2 ve 3 numaralı rotalara gitmeyi tercih ederim. Temelde # 1 endişelerin ayrılmasını ihlal eder ve her türlü şeyi karıştırır. Sonunda, eşleşen bir HTML sayfası / vb. Olmayan bir API bitiş noktasına sahip olmanız gerektiğini görürsünüz ve aynı kod tabanındaki iç içe HTML ve JSON uç noktaları ile bir dereye girersiniz. MVP'si olsa bile, sonunda yeniden yazmanız gerekecek, çünkü çok dağınık olduğu için kurtarmaya bile değmeyeceği için korkutucu bir karmaşaya dönüşüyor.

# 2 veya # 3 ile devam etmek, aynı şekilde (çoğunlukla) aynı şekilde davranan bir API'ye sahip olmanızı sağlar. Bu büyük esneklik sağlar. Henüz% 100 Backbone / ember / whatever / etc.js'de satılmadım. Bence harika, ama twitter ile gördüğümüz gibi bu uygun değil. AMA ... Twitter aynı zamanda bir şirketin büyük bir canavarıdır ve yüz milyonlarca kullanıcıya sahiptir. Bu nedenle, herhangi bir iyileşmenin, çeşitli iş birimlerinin çeşitli alanlarındaki kârlılık üzerinde büyük etkisi olabilir. Kararda sadece hızdan daha fazlası olduğunu düşünüyorum ve bu konuda bize izin vermiyorlar. Ama bu sadece benim görüşüm. Ancak, omurga ve rakiplerine indirim yapmıyorum. Bu uygulamaların kullanımı harika ve çok temiz ve çok duyarlı (çoğunlukla).

Üçüncü seçenek de geçerli bir cazibeye sahiptir. Burası, Pareto prensibini (80/20 kuralı) izlediğim ve ana işaretlemenizin% 20'sini (veya tersini) sunucuda oluşturduğum ve daha sonra güzel bir JS istemcisine (omurga / vb.) . REST api ile% 100 JS istemcisi üzerinden iletişim kurmuyor olabilirsiniz, ancak daha iyi bir deneyim sağlamak için gerekirse biraz iş yapacaksınız.

Bence bu, bu "sorunlara bağlı" türlerden biridir ve cevap "ne yaptığınıza, kime hizmet ettiğinize ve ne tür deneyimler almanızı istediğinize bağlıdır." Sanırım 2 veya 3 veya bir hibrit arasında karar verebilirsiniz.

Şu anda büyük bir CMS'yi seçenek 1'den seçenek 3'e dönüştürmeye çalışıyorum ve iyi gidiyor. İşaretleme sunucu tarafını oluşturmayı seçtik çünkü SEO bizim için büyük bir anlaşma ve sitelerin cep telefonlarında iyi performans göstermesini istiyoruz.

İstemcinin arka ucu için node.js ve bana yardımcı olacak birkaç modül kullanıyorum. Süreçte biraz erken geliyorum ama vakıf kuruldu ve her şeyin doğru olmasını sağlayan verilerin üzerinden geçme meselesi. İşte ne kullanıyorum:

• Uygulamanın temeli için Express.
  (https://github.com/visionmedia/express)
• Verileri getirme isteği.
  (https://github.com/mikeal/request)
• Oluşturulan sunucu tarafı olan alt çizgi şablonları. Bunları istemcide yeniden kullanıyorum.
  (https://github.com/documentcloud/underscore)
• UTML, Express ile çalışmalarını sağlamak için alt çizgi şablonlarını sarar.
  (https://github.com/mikefrey/utml)
• Peki, şablonları toplar ve hangisini istemciye gönderileceğini seçelim.
  (https://github.com/mrDarcyMurphy/upfront)
• Express Expose, getirilen verileri, bazı modülleri ve şablonları kullanıcı arabirimine aktarır.
  (https://github.com/visionmedia/express-expose)
• Omurga, aktarılan verileri yuttuktan sonra ön uçta modeller ve görünümler oluşturur.
  (https://github.com/documentcloud/backbone)

Bu yığının çekirdeğidir. Yararlı bulduğum diğer bazı modüller:

• fleck (https // github.com / trek / fleck)
• moment (https // github.com / timrwood / moment)
• ekran kalemi (https // github.com / LearnBoost / ekran kalemi)
• smoosh (https // github.com / fat / smoosh)
  … homurdanmaya bakıyorum (https // github.com / kovboy / grunt)
• konsol izleme (//github.com/LearnBoost/console-trace).

Hayır, kahve kullanmıyorum.

Bu seçenek benim için gerçekten iyi çalışıyor. Arka uçtaki modeller mevcut değildir, çünkü API'den aldığımız veriler iyi yapılandırılmıştır ve onu ön uçlara aynen geçiriyorum. Tek istisna, oluşturmayı daha akıllı ve daha hafif hale getiren tek bir özellik eklediğim düzen modelimiz. Bunun için herhangi bir fantezi model kütüphanesi kullanmadım, sadece başlangıçta ihtiyacım olanı ekleyen ve kendini döndüren bir işlev.

(garip bağlantılar için özür dilerim, yığın taşması için bu kadar çok posta göndermeme izin verecek kadar fazla bir n00b)

Şu 3 numaralı varyantı kullanıyoruz: Yalnızca JSON REST API sunucusu yapın. Bir HTML web sitesi sunucusu oluşturun. HTML web sunucusu, varyantınızdaki gibi REST API sunucusunun istemcisi değildir. Bunun yerine, ikisi akranlardır. Yüzeyin çok altında olmayan, iki sunucunun ihtiyaç duyduğu işlevselliği sağlayan dahili bir API vardır.

Herhangi bir emsal olduğunun farkında değiliz, bu yüzden biraz deneysel. Şimdiye kadar (beta'ya girmek üzere), oldukça iyi çalıştı.

Genellikle API oluşturmak için Rails ve JS şeyler için omurga kullanarak 2. seçenek için gidiyorum. Hatta ücretsiz olarak bir yönetici paneli alabilirsinizActiveAdmin'i . Bu tür bir arka uçla onlarca mobil uygulama gönderdim. Ancak, uygulamanızın etkileşimli olup olmamasına büyük ölçüde bağlıdır.

Son RubyDay.it'te bu yaklaşımla ilgili bir sunum yaptım : http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

Üçüncü seçenek için, ikincisinin yanıt verebilirliğini elde etmek için, Github'ın yaptığı gibi pajax'ı denemek isteyebilirsiniz .

Burada özetlediğiniz ikinci yaklaşımı benimseyen 3 aylık bir projeye 2 ay kalacağım. Önde backbone.js bulunan bir RESTful API sunucu tarafı kullanıyoruz. Handlebars.js şablonları yönetir ve jQuery, AJAX ve DOM manipülasyonunu işler. Eski tarayıcılar ve arama örümcekleri için sunucu tarafı oluşturma işlemine geri döndük, ancak Mozilla Rhino kullanan Gidonların ön ucuyla aynı HTML şablonlarını kullanıyoruz.

Bu yaklaşımı birçok farklı nedenden dolayı seçtik, ancak henüz geniş çapta kanıtlanmadığı göz önüne alındığında, biraz riskli olduğunun farkındayız. Aynı şey, şimdiye kadar her şey çok sorunsuz gidiyor.

Şimdiye kadar sadece bir API ile çalışıyoruz, ancak projenin bir sonraki aşamasında ikinci bir API ile çalışacağız. Birincisi büyük miktarda veri içindir ve ikincisi daha çok bir API yoluyla bir CMS gibi davranır.

Projenin bu iki parçasının birbirinden tamamen bağımsız davranması, bu altyapının seçilmesinde önemli bir husustur. Herhangi bir bağımlılık olmadan farklı bağımsız kaynakları karıştırmak için bir mimari arıyorsanız o zaman bu yaklaşım bir göz atmaya değer.

Korkarım Ruby adam değilim, bu yüzden diğer yaklaşımlar hakkında yorum yapamam. Bazen risk almak iyidir. Diğer zamanlarda güvenli oynamak daha iyidir. Proje türüne bağlı olarak kendinizi borçlu olacaksınız.

Burada seçim ile iyi şanslar. Başkalarının da neler paylaştığını görmek istiyor.

Web sitem, verilerimin% 100 CRUD uygulaması olmayacaksa # 3'ü seviyorum. Bu henüz gerçekleşmedi.

Sinatra'yı tercih ediyorum ve uygulamayı farklı amaçlarla birkaç farklı raf uygulamasına ayıracağım. Ben API için gerekenler kapsayacak bir API özel raf uygulaması yapacağım. Sonra belki de web sayfamı sunacak bir kullanıcı raf uygulaması. Bazen bu sürüm gerekirse API'yi sorgular, ancak genellikle sadece html sitesi ile ilgilenir.

Bu konuda endişelenmeyin ve gerekirse kullanıcı tarafından bir kalıcılık katmanı sorgusu yapın. Genellikle farklı amaçlara hizmet ettikleri için tam bir ayrılık yaratmakla aşırı ilgilenmiyorum.

İşte bir çok çoklu raf Uygulamaları kullanmanın basit bir örnek. API uygulamasına çarptığını görmek için buraya hızlı bir jquery örneği ekledim. Sinatra ile ne kadar basit olabileceğini ve farklı amaçlarla birden fazla raf uygulaması monte etmeyi görebilirsiniz.

https://github.com/dusty/multi-rack-app-app

Burada bazı harika cevaplar - kesinlikle # 2 veya # 3 tavsiye ederim - ayırma kavramsal olarak ama pratikte de iyidir.

Bir API üzerindeki yük ve trafik modelleri gibi şeyleri tahmin etmek zor olabilir ve API'ya bağımsız olarak hizmet veren müşterilerimiz için daha kolay bir hazırlık ve ölçeklendirme zamanı vardır. Bunu insan web erişim kalıpları ile munged yapmak zorunda daha az kolaydır. Ayrıca API kullanımınız web istemcinizden çok daha hızlı ölçeklenebilir ve ardından çabalarınızı nereye yönlendireceğinizi görebilirsiniz.

# 2 # 3 arasında gerçekten hedeflerinize bağlı - # 2'nin muhtemelen webapp'lerin geleceği olduğuna katılıyorum - ama bu kanal sadece birçoğundan biri olacaksa belki daha basit bir şey istersiniz!

Atyourservice.com.cy için, özellikle se bölümünü kapsamak üzere sayfalar için sunucu tarafında oluşturulmuş şablonlar kullanıyoruz. Ve sayfa yüklendikten sonra etkileşimler için API'yı kullanma. Çerçevemiz MVC olduğundan tüm denetleyici işlevleri json çıkışı ve html çıkışına çoğaltılır. Şablonlar temizdir ve yalnızca bir nesne alır. Bu saniyeler içinde js şablonlarına dönüştürülebilir. Sunucu tarafı şablonlarını her zaman koruruz ve sadece istek üzerine js'ye dönüştürürüz.

İzomorfik görüntü oluşturma ve aşamalı geliştirme. Üçüncü seçenekte gittiğinizi düşünüyorum.

izomorfik oluşturma , istemci tarafı kodunda kullandığınız şekilde sunucu tarafı biçimlendirmesi oluşturmak için aynı şablonu kullanmak anlamına gelir. İyi sunucu tarafı ve istemci tarafı uygulamaları ile cazip bir dil seçin. Kullanıcılarınız için tamamen pişmiş html oluşturun ve kabloyu gönderin. Önbelleği de kullanın.

aşamalı geliştirme , tüm kaynakları indirdikten ve istemci yeteneklerini belirledikten sonra istemci tarafında yürütme ve oluşturma ve olay dinleme yapmaya başlamak anlamına gelir. Erişilebilirlik ve geriye dönük uyumluluk için mümkün olan her yerde işlevsel komut dosyası içermeyen işlevselliğe geri dönme.

Evet, elbette bu uygulama işlevselliği için bağımsız bir json api yazın. Ama o kadar ileri gitmeyin, statik html belgeleri olarak iyi çalışan şeyler için bir json api yazabilirsiniz.

REST sunucusu + JavaScript ağırlıklı istemci son çalışmamda izlediğim ilkeydi.

REST sunucusu node.js + Express + MongoDB (çok iyi yazma performansı) + Mongoose ODM (verileri modellemek için harika, doğrulamalar dahil) + CoffeeScript (şimdi bunun yerine ES2015'e giderdim) için uygulandı. Node.js, diğer olası sunucu tarafı teknolojilerine kıyasla nispeten daha genç olabilir, ancak ödemeleri entegre olarak sağlam bir API yazmamı sağladı.

Ember.js'yi JavaScript çerçevesi olarak kullandım ve uygulama mantığının çoğu tarayıcıda yürütüldü. SASS kullandımCSS ön işleme için (özellikle SCSS) .

Ember, güçlü toplum tarafından desteklenen olgun bir çerçevedir. Yepyeni Glimmer renderleme motoru ( React'tan esinlenerek) gibi son zamanlarda performansa odaklanan çok sayıda işin yapıldığı çok güçlü bir çerçevedir .

Ember Core Team, JavaScript Ember mantığınızı sunucu tarafında (özellikle node.js) çalıştırmanızı ve uygulamanızın önceden oluşturulmuş HTML'sini (normalde tarayıcıda çalıştırılacaktır) kullanıcıya göndermenizi sağlayan FastBoot geliştirme sürecindedir . Sayfanın görüntülenmesi için uzun süre beklemediği için SEO ve kullanıcı deneyimi için harika.

Ember CLI , kodunuzu düzenlemenize yardımcı olan harika bir araçtır ve büyüyen kod tabanıyla ölçeklendirmek için iyi bir iş çıkardı. Ember ayrıca kendi eklenti ekosistemine sahiptir ve çeşitli Ember Eklentileri arasından seçim yapabilirsiniz . Bootstrap'i (benim durumumda) veya Foundation'ı kolayca alıp uygulamanıza ekleyebilirsiniz.

Express aracılığıyla her şeye hizmet etmemek için, resim ve JavaScript ağırlıklı istemci sunmak için nginx kullanmayı seçtim. Benim durumumda nginx proxy kullanmak yardımcı oldu:

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Pro: API ve istemcinin ayrılmasını seviyorum. Akıllı insanlar bunun yolunun olduğunu söylüyor. Teoride harika. Modern ve heyecan verici görünüyor.

Pratikte de harika diyebilirim. REST API'sini ayırmanın diğer bir avantajı, daha sonra başka uygulamalar için tekrar kullanabilmenizdir. Mükemmel dünyada aynı REST API'sini yalnızca web sayfası için değil, aynı zamanda bir tane yazmaya karar verirseniz mobil uygulamalar için de kullanabilmelisiniz.

Con: Pek emsal değil. Bunun pek bir örneği iyi yapılmadı. Herkese açık örnekler (twitter.com) halsiz ve hatta bu yaklaşımdan uzaklaşıyor.

Şimdi işler farklı görünüyor. REST API + bunu kullanan birçok müşteri yapmanın birçok örneği var.

Infiniforms için Seçenek # 2 mimarisine gitmeye karar verdim iş mantığından ayırmak için harika bir yol sağladığı .

Bunun bir avantajı, API Sunucularının web sunucularından bağımsız olarak ölçeklendirilebilmesidir. Birden fazla istemciniz varsa, web sitelerinin web sunucularıyla aynı ölçüde ölçeklendirilmesi gerekmez, çünkü bazı istemciler telefon / tablet veya masaüstü tabanlı olacaktır.

Bu yaklaşım, özellikle web siteniz için tüm işlevleri sağlamak için kendi API'nizi kullanıyorsanız, API'nizi kullanıcılarınıza açmak için iyi bir temel sağlar.

Çok güzel bir soru ve bu günlerde çok yaygın bir görev olduğunu düşündüğüm için şaşırdım, böylece bu sorun için çok fazla kaynağa sahip olacağım, ancak doğru olmadığı ortaya çıktı.

Düşüncelerim olarak aşağıdaki gibidir: - API kontrolörleri ve HTML kontrolörleri arasındaki ortak mantığı olan bazı modül oluşturun olmadan nedenle örneğin, ne istersen sonra veya oluşturma html ve HTML kontrolörü ve API denetleyicisi hem de bu modülü dahil, json dönen :

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end

Sinatra'yı temel olarak kullandığımız, ActiveRecord / Postgress vb. Sayfa yollarını (ince şablonlar) web uygulamasının kullanabileceği bir REST API'sini ortaya çıkarmak için kullandığımız karma bir yaklaşıma gittim. Seçme seçeneklerini doldurma gibi erken geliştirme işlemlerinde, ince şablona dönüşen yardımcılar aracılığıyla yapılır, ancak üretime yaklaştıkça, sayfa yükleme hızları vb.

Slim'te işlenmesi kolay olan şeyler bu şekilde halledilir ve şeyler (formları doldurmak, jQuery'den form POST verileri almak .Validation'ın submitHandlervb . Hepsi açıkça AJAX)

Test etmek bir konudur. Şu anda JSON verilerini Rack :: Test POST testine geçirmeye çalışıyorum .

Ben şahsen (3) seçeneğini çözüm olarak tercih ediyorum. Eski bir işverenin sahip olduğu hemen hemen tüm sitelerde kullanılır. Bu, Javascript, tarayıcı tuhaflıkları ve ön ucunuzu kodlamak için ne yapacağınız hakkında her şeyi bilen bazı ön uç geliştiricilere sahip olabileceğiniz anlamına gelir. Onlar sadece "kıvırmak xyz bilmek gerekir ve bazı json alacaksınız" ve kapalı gidiyoruz.

Bu arada, ağır ağırlıktaki arka uç adamlarınız Json sağlayıcılarını kodlayabilir. Bu adamların sunum hakkında hiç düşünmelerine gerek yoktur ve bunun yerine kesintili arka uçlar, zaman aşımları, zarif hata işleme, veritabanı bağlantı havuzları, iplik geçirme ve ölçekleme vb.

Seçenek 3 size iyi, sağlam üç katmanlı bir mimari sunar. Ön uçtan tükürdüğünüz şeyler SEO dostu, eski veya yeni tarayıcılarla (ve JS kapalı olanlarla) çalışmak için yapılabilir ve isterseniz Javascript istemci tarafı şablonu oluşturabilir (böylece eski tarayıcıları / googlebot'u statik HTML ile işlemek gibi şeyler yapın, ancak en son Chrome tarayıcıyı veya diğerlerini kullanan kullanıcılara JS tarafından oluşturulmuş dinamik deneyimler gönderin).

Seçenek 3'ü gördüğüm tüm durumlarda, Açık Kaynak arazisine bırakılmaksızın, projeler arasında özellikle aktarılamayan bazı PHP'nin özel bir uygulamasıydı. Sanırım daha yakın zamanda PHP Ruby / Rails ile değiştirilmiş olabilir, ama aynı şey hala doğrudur.

FWIW, $ current_employer birkaç önemli yerde Seçenek 3 ile yapabilirdi. Bir şey inşa etmek için iyi bir Ruby çerçevesi arıyorum. Eminim bir sürü mücevherleri birbirine yapıştırabilirim, ancak genel olarak bir şablonlama, 'kıvırma', isteğe bağlı kimlik doğrulama, isteğe bağlı memcache / nosql bağlantılı önbellek çözümü sağlayan tek bir ürünü tercih ederim. Orada tutarlı bir şey bulamıyorum :-(

Rails içinde bir JSON API oluşturmak birinci sınıf, JSONAPI :: Resources gem http://jsonapi.org spesifikasyon API için ağır kaldırma yapar .