Vladimir Angelov
New Member
Стараем се всякакви такива неща да се зареждат след като страницата е "заредила" статичната част от съдържанието, където е възможно. Всъщност в момента не се сещам за интеграция, където не е възможно. Т.е. това по никакъв начин няма да наруши user experience-а. Евентуално ако избереш да си интегриран с много такива ще смучеш повече трафик и батерия на мобилни устройства на хората, но всичките по отделно са optional, т.е. това че ги има интегрирани всичките, не значи че те ще товарят всеки един магазин ако не са включени всичките.
Ако имаш предвид дали всички магазини ще са хостнати на една машина - твърдо не. Имаме си изградена система за distributed deployment. Също така всеки магазин си има абсолютно собствена и напълно изолирана база от останалите.
Ако имаш предвид дали един магазин ще може да бъде хостнат едновременно на няколко машини, поради твърде обемен load - това все още не сме го имплементирали и едва ли ще ни бъде в плана за 2019. Но по-натам ще се наложи най-вероятно.
Със сигурност това би било много добре, но се съмнявам, че ще е възможно
XML Import - да. Не съм запознат конкретно с All Import Pro за да кажа дали ще е същото. Автоматично ъпдейтване през определено време - нямаме планирано за момента, но не звучи като нещо сложно да се имплементира ако има желание от потребителите. Ще го имаме предвид.
Затова започнах с "въпреки маркетинговото звучене на фразата, ще се опитам..."чудесно, изброи няколко покемона
Със сигурност конкретния технологичен стак не ни дава някакви свръхестествени възможности, нечувани в другите езици за програмиране и технологии, но според мен ни дава edge в доста отношения.Прав си, че изглежда измамно с демо страничка, но по наши измервания при реалния магазин засега няма значителна разлика от това, което се вижда сега. Вéрвайте ми
Неща, които не се случват мигновено в реалния магазин са - зареждане на резултати от търсене, потвърждаване на закупуване, логин, и общо взето неща, които изискват roundtrip до базата и юзърския интерфейс има нужда от response за да направи визуализация. Например добавяне на продукт в количка, смяна на страница и отваряне на количката ще бъдат мигновени операции, тъй като не изискват потвърждаване от бекенда.Като RAM usage и трафик числата са по-големи, просто защото има повече картинки и повече елементи по страниците.
Засега това мога да кажа. Пък другото - поживём — увидим.
Да. Възможно е това да не е част от бетата обаче.
На roadmap-а ни е, но едва ли в първия релийс.
Извинявам се за забавянето. Дали все пак успях да отговоря на въпроса?Здравейте, още чакам отговор какво ще правите към външните ресурси
Това е добър фийдбек. Това, което си мисля е, че най-добре за него да му изкараме просто един дебел warning, че това което прави може да резултира в кофти перформънс за неговия магазин, пък той на своя глава вече да прави каквото иска. По-apple-ския подход би бил вместо warning директно да му забраним да прави неща, които биха могли да доведат до кофти перформънс, с цел да пазим бранда, но мисля че това е твърде крайно.
Отделно част от deployment pipeline-а ни е автоматичен анализ на това кои части от страниците се виждат при първоначално отваряне и всички по-тежки ресурси (картинки), които са извън границите на очаквания viewport се lazy-load-ват след като е приключило първоначалното зареждане на страницата. Т.е. освен ако тези 8 слайдера не се виждат едновременно на екрана, няма да е чак такъв ужас. Даже бих казал изобщо.
THIS GUY GETS IT
Не съм сигурен дали разбирам напълно въпроса, но реално след като всичко е хостнато на машини, до които само ние имаме достъп, инсталирайки си модули от маркетплейса, ти реално няма да имаш достъп до техния сорс код. Единствения, който може да ти го открадне, сме ние.
Да.
Да.
Здравей, хейтър,
Ето вече имаме поне един ентусиаст и той да ни прави компания в маркетплейса, така че всичко е точно
