• Підхід при плануванні архітектури веб-проєкту

    Скільки наразі коментів в базі форума, скільки йде паралельно запитів на читання, редагування та додавання нових коментів?

    Це майже немає значення. Навіть якщо ті всі запити не будуть виконуватися паралельно, та стануть в чергу з латенсі в 2-10 мс, це десь 100-500 запитів за секунду.

    Але в ДОУ навантаження більше, а в Реддіта — ще більше

    В доу навантаження невелике. Може 1-2 комента за хвилину в середньому. Перегляди, ну може 10 за хвилину.

    Але то все не має значення. Цифри можуть бути більші, меньші. Просто як приклад.

  • Підхід при плануванні архітектури веб-проєкту

    Що і що ми порівнюємо. Якщо кратко.
    Реляційні бази данних VS K/V VS Documented,
    якщо мова про дерева — виграють останні.

    А теперь мінутка практікі, форум RawForum
    Середній час обробки запиту, навіть без кешів, від 2 до 10 мс.
    Амінь.

    fraplat.com/...​9a712.png&newSession=true

  • Підхід при плануванні архітектури веб-проєкту

    Все пізнається в порівняні. Якщо в вас дерево лежить в реляційній базі в структурі (Id, ParentId), то воно буде працювати приблизно на два порядки повільніше ніж, якщо воно буде лежати в древовидній якісь k\v структурі.
    Я думаю доу виживає тільки тому, що кешує повністю сторінки.
    Але ФП теж таке вміє і значно ефективніше. Через ReactCache.

  • Підхід при плануванні архітектури веб-проєкту

    поки все, що «тестують» ваші випадкові юзери — генерує баги.

    В мене в клауді всі ходи записані.
    Правий нижній графік — healthy, помилки що генерували додатки . Сьогодні їх не було. Доречі це все теж написано на ФП. Що у вас там з готових фреймворків є, якщо я хочу написати аналітику, багато аналітики, для клауду?

    fraplat.com/...​44d9c.jpg&newSession=true

  • Підхід при плануванні архітектури веб-проєкту

    Треба пробувати. Як я навчився то і інші навчатся. Моя мета була спростити розробку на скільки тільки можна. Я її спростив.

    Підтримав: Denys Poltorak
  • Підхід при плануванні архітектури веб-проєкту

    В вас немає грошей, але ви хочете доу безкоштовно? Так не працює. Доу на пхп писати 2-3 місяці, я можу зробити вам знижку 50% але це все одно буде дорого. Безкоштовно тільки RawForum з шоуруму.

    коли трапляється задача з реального життя, а не ваша віртуальна,
    то починається «дайте грошей»

    Там документоорієнтована база та key/value storages.
    Дерева там як риба в воді, на відміну від пхп та реляціонок. Чи ви думали що прискорення розробки та швидкості в х10 разів можна отримати на класичних технологія ? Звісно ні. На то має бути підгрунтя.

  • Підхід при плануванні архітектури веб-проєкту

    Там немає нічого складного.
    Я навіть колись перевіряв через GPT, береш любий код з мого прикладу, та питаєш в нього. Він тобі розказує, хоча навіть ніколи не бачив ФП в житті.
    Бо код дуже простий, та зрозумілий.

    Це ще одна перевага ФП, коду не тільки значно меньше, він значно більш зрозумілий та структурований. Підійми мене серед ночі, я тобі розкажу як працює любий з 25 проєктів. Не тому що я розумний, тому що з кодом дуже легко розібратися.

    Як би ти спробував, відразу зрозумів.

  • Підхід при плануванні архітектури веб-проєкту

    Мені нема сенсу, щось комусь персонально доводити.
    Якщо ви хочете замовити подібну роботу на платній основі, я зроблю.
    Ви же не кидаєтесь робити на ПХП навіть сайт з погодою, хоча на ФП там два функціональні вирази та пів години роботи, а на пхп два дні роботи.

    І якщо захочете персональний доу, вам бонус. Темами на 10к коментів буде значно швидше оперувати ніж оригінал.
    Так вже сталось, що ця «бричка» їздить швише ніж оригінали. Це можна навіть побачити по наявним веб прикладам, що там час опускається до 12-15 мс на відповідь.

  • Підхід при плануванні архітектури веб-проєкту

    Що саме бричка ?
    Це клон sqlnet форуму, майже один в один.
    Такий самий клон можна створити на доу, один в один.
    Ну не за два-три дні. Я писиміст. Але за тиждень+ можна.

  • Підхід при плануванні архітектури веб-проєкту

    Джанго був таким бустом

    Джанго то типове MVC, якщо не помиляюсь.
    Тобто ніякого бусту в порівнянні з тим же ASP.NET MVC не дасть. Такий як і всі інші. На клонування доу я би на ньому брав місяць або краще два, що найменьше.

  • Підхід при плануванні архітектури веб-проєкту

    А чому з нуля? Хіба фреймворків нема?

    Томущо фреймворки то не дуже гнучке рішення.
    Ось приклад, є така доробка для сайту форуму, реєструвати користувачів прямо в темі
    velokyiv.com/...​iewtopic.php?f=1&t=177212

    І ? На якому фреймворку це можливо ?
    Якщо я не використовув фреймворк, яб таку функціональність докинув за годину, а не вичитував мануали та думав як натягнути сову на глобус в черговому фреймворку.

  • Підхід при плануванні архітектури веб-проєкту

    Це одвічне питання. Чому в інтернеті немає лише одного сайту з погодою, бо другий за такою логікою вже зайвий. Або якщо є ютуб, то чого є ще 500 сервісів які крутять відео в інтернеті.
    Якщо ти питаєш чому я створював свої версії цих сервісів.
    1. Протестити платформу, що це дійсно можливо
    2. Погоду показує без банерів. Відео ютуб крутить без реклами.
    Захватувати ринок не планував, для цього треба щоб розробку ініціював маркетолог, який знає як просувати продукти. Але в мене не було такої мети. Це тестові продукти, для власного користування + ще для когось, кому потрібно.

  • Підхід при плануванні архітектури веб-проєкту

    мене років з 10-12 тому намагались перевчити на Ruby on Rails — суто для одного проекту, бо замовник знав Ruby, але не знав PHP.

    Так ти упускаєш головну деталь. Ні рубі ні пхп тобі не дасть якогось великого буста, скажімо, при клонуванні доу (чи підстав інший проєкт).
    Це дві майже рівнозначні технології. Якщо вони рівнозначні, то навіщо щось вчити нове? Тобто що там, що там місяць роботи.
    А ФП дасть, і це буде лише тиждень роботи. Тож навіть якщо це будет тиждень навчання + тиждень розробки, все одно це буде в два рази швидше ніж на рубі чи пхп.

  • Підхід при плануванні архітектури веб-проєкту

    Коли він почне окупатись?

    Він був написаний, бо це зайняло рівно 15 хвилин.
    Як би це зайняло пару годин, або як на класичних засобах розробки — день, я би його вже не писав.

    Тож, якщо він буде використаний, нехай для завантаження лише 100 малюнків в інтернеті, та не буде дратувати банерами мене та інших, буду вважати що він окупив 15 хвилин мого часу =)

    Підтримав: Denys Poltorak
  • Підхід при плануванні архітектури веб-проєкту

    А навіщо він треба, коли їх є купа безкоштовних?

    Тепер до купи є ще один безкоштовний, без банерів

  • Підхід при плануванні архітектури веб-проєкту

    для порівняння — в мене фронт забирає приблизно стільки ж часу, скільки і бек на ПХП,
    то я так собі прикидаю, що він себе сильно переоцінив,

    Так навіщо далеко бігати.
    Ось же є форум, який написаний на 350 рядків коду.
    fraplat.com/jupiter/RawForum
    github.com/...​um/RawForumApplication.cs

    Там є
    У функціональності для користувача: реєстрація, логін, створення топіків, створення повідомлень, перегляд того, хто і коли зареєстрований, цитування повідомлень.
    У функціональності для адміністратора: редагування категорій / топіків / користувачів.

    Цей форум в мене зайняв 2(3) дні розробки (чи ви не вірите що 2 дні вистачить щоб написати 350 рядків коду?).

    А тепер головне питання. Скількі з аналогічною функціональністю форум буде коштувати з нуля на ПХП

  • Підхід при плануванні архітектури веб-проєкту

    Для любого проекту потрібна технологія, на котрій легко можна знайти заміну девелоперу, а не кожного разу витрачати гроші на те, щоб навчити ще одного девелопера.
    Також більшість девелоперів не захоче вчити те, що їм знадобиться лише для одного проекту — це мертві знання.

    А чому саме для одного проєкту? Це універсальна та добре масштабована платформа, яка в плюс має вийти вже з першими клієнтами. А те що вона отримує перших клієнтів — навіть не сумнівайтесь. Мене тішить, що навіть коли є лише один клієнт (лише я, наприклад, лол)
    ФП генерить корисні проєкти один за одним.
    Seasons — онлайн кінотеатр
    Weather — сайт з погодю
    ImageHosting — хостінг малюнків
    VideoLibrary — портал для перегляду 3д відео
    WorkOutTracker — щоденник для спортивних результатів
    RawForum — форум
    UTube — прототип ютуба з каналами
    BTCRate — котировки біткоїна
    та багато іншого.

    Я вважаю що це добрий знак. ФП генерує ринок там, де його не мало би бути.
    Це доречі кумедно, але ловлю себе на думці, що ФП треба було створити хочаб лише для того, щоб зрозуміти наскільки швидко можна створювати будь-які додатки під себе, та задовільнити хочаб свій власний попит.

    Я маю досвід комерційної розробки з 2003 року, ще від Дельфі 4 і ПХП 3,
    і я також писав повністю самописні продукти.
    тож на свому досвіді знаю ваші перспективи.

    Це добре, та заслуговує поваги.

  • Підхід при плануванні архітектури веб-проєкту

    Якщо вже є готовий движок який повністю відповідає вимогам стартапу, та істотні півоти стартапу не світять, то звісно треба брати та не морочити голову з ФП )
    Але, якщо щось готове знайти довше, чим написати на ФП, то треба брати ФП.
    Ось коли мені потрібен був вчора fraplat.com/jupiter/ImageHosting, сервіс для анонімного завантаження фото в інтернеті, накшталт ibb.co тількі без банерів та виїзджаючих меню, я його створив за 15 хвилин під себе.

  • Підхід при плануванні архітектури веб-проєкту

    1) Bus factor, воєнкомат 2) Можливі архітектурні негаразди всередині платформи 3) Прийшов більший юзер, що має більше грошей, і хоче від вас щось інше вотпрямщас. 4) Фігвіддебажиш.

    Скажу дуже коротко. Вибору нема. Або дістань з кишені умовних $20к вже на старті, на проєкт що 90% не взлетить/не буде прибутковим,
    або візьми інструмент ефективніший на х10, але з певними ризиками вижче.

    Поки комуніті розмірковує, які технології краще, на ФП за останній тиждень додалось ще три нових невеликі проєкти: ImageHosting, SiteScanner, Electricity.
    Вони б просто не могли бути створені, якщо б їх писали на класичних засобах розробки. Це просто не вигідно, перш за все по часу розробки.
    З ФП це стає економічно доцільним, навіть якщо сервіс потрібен всього кільком людям.

  • Підхід при плануванні архітектури веб-проєкту

    А грошей — вже нема)

    Не зовсім зрозуміло, як гроші можуть за два тиждні закінчиться. =)
    Як же тоді засновник планував місяці з командою витрачати на розробку.

    З іншого боку, якщо щось піде не так в ранньому проді — то усе згоріло, бо платформа неперевірена, комьюніті нема, підтримки — також нема.

    Якщо чесно, це майже виключено. Цю платформу я знаю як свої пять пальців, як зовсім піде все погано, я докостиляю на С# та С++ будь-які кастомні штуки, потягне будь-які мейнстрімні навантаження.

    От якщо взяти умовний bubble, та впертися в якісь обмеження на фундаментальному рівні, от там так. Ніхто спеціально під тебе платформу міняти не буде.

← Сtrl 1... 34567...9 Ctrl →