Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 63
только будет нужна многопоточка с менеджем того вызова малок, чтобы не было утечки, можно углубиться в воксели и там посмотреть как работает многопоточка(потом с полученными ) знаниями попробовать переосмыслить многопотоковый сервер с менеджером ресурсов без утечек )
мне тематика вокселей вообще раскрыла глаза сейчас как мне кажется, там четко прям видна архитектура управления ресурсами
Зашёл в статью из-за девушки на экране.
Оказалось, она тут ни при чём.
В рай она не попадёт
Интересная статья про минималистичный веб! Вышло здорово, в очередной раз показывает, что хорошее обращение с матчастью позволяет творить чудеса оптимизации :)
Посыл про компактность поддерживаю, сейчас такого мало. Но вот что сразу на ум пришло:
Маленький код проще прочитать и проаудитить. Но у «маленького веба» почти всегда отсутствует то, что делает сервер безопасным и предсказуемым в проде (да и просто при выставлении «голой задницей наружу»): годы работы в реальных условиях, совместимость по всем подробностям протокола, в т.ч. и с капризными и «маленькими» (как аллюзия на «маленький сервер») клиентами, покрытие тестами, эксплуатационные ограничения. В самой статье, кстати, автор упоминает риски «неполной реализации, безопасностью, работой под нагрузкой».
Если всё это не закрывается — «красота и услада» остаются, но продовая эксплуатация превращается в рулетку: не потому что код сервера плохой (хотя автор пишет не всё сам, а использует чужие либы, скажем), а потому, что веб‑периметр нынче «жёсткий», и у больших серверов большая часть сложности — это плата за «выживание в реальности».
Дарвин какой-то получается.
Можно упомянуть протокол Gemini для маленького интернета, Gopher, сообщество tilde, мастодон. Маленький веб всегда был, надо только поискать.
Браво! Мне конечно до такого далеко, приятно видеть что кто-то понимает что комбайны-монстры не решают.
Я тоже за минимализм. В профиле — пет-проект "мини-CRM для самых маленьких", и мне пока непонятно нужно ли кому такое. Или у всех "маленьких" уже оплачена подписка на корпоративщину типа 1С-управление-чего-то-там.
Никогда не видел таких толстых (широких) домов, как на фото с девушкой. Или это дом буквой "Г"?
большой объем чужого исходного кода под капотом вашего проекта будет висеть гирей и отвлекать ресурсы на поддержку, в отличие от чего-то маленького и простого;
борьба с энтропией — популярные библиотеки постоянно растут и раздуваются, при этом объем используемого функционала не особо меняется. Таким образом, большая часть кода в современном проекте с кучей внешних библиотек не используется никогда.
Вот это как по мне очень распространенная обманка, которая губит массу проектов.
Реальный мир сильно иначе работает и успех всех этих крупных систем с массой встроенного функциона обусловлен именно потребностями реального мира.
Я помню это еще на пример MS Office одно время были очень популярны обсуждения в духе, что обычный пользователь использует дай бог 5% его функционала.
И вроде бы еще Джоел Спольски писал статью, в которой очень справедливо отметил, что каждому отдельному пользователю может и нужно всего 5% функционала, вот только разным пользователям нужны разные 5% функционала.
И сейчас это так же верно и для фреймворков в программировании например - сейчас мне нужно только 5% функционала, другим нужно другие 5%, а потом изменятся требования к моему проекту и мне тоже понадобятся другие 5%.
В итоге система, в которой будут только эти 5%, никогда не обретет массового успеха и не получит экосистемных преимущество - накопленной базы документации, ответов и вопросв (в наша время обученных LLM), большого количества знающих ее соглашения людей и следовательно простоты нахождения сотрудников.
Но для обучения и образования такие маленькие проекты, конечно, очень полезны.
Реальный мир сильно иначе работает и успех всех этих крупных систем с массой встроенного функциона обусловлен именно потребностями реального мира.
Я тут гадаю с чего откровенно проходная статья привлекла столько внимания, а вы на полном серьезе рассказываете о причинах мировой славы и успеха у очень известных проектов..
Просто в век копроративного "всего для всех" мы уже соскучились по минималистическому подходу...
Э-э... а вы самокритичны, ну так интернет работает и Хабр, кто-то случайно видит статью просто потому, что именно в это утро решил немного времени листанию Хабра посвятить, видит в ней цепляющее его утверждение о котором сам не раз раньше думал и реагирует в комментариях.
система, в которой будут только эти 5%, никогда не обретет массового успеха
Сходу приходит на ум sqlite, который без огромного количества фич Oracle или Postgres используется более чем массово. Или какие-нибудь cat/grep/less... Так что минималистичные библиотеки/инструменты, хорошо решающие одну конкретную задачу, вполне востребованы.
grep/less не светят в интернет, лишней точкой в regexp сложно устроить себе RCE
Sqlite я бы не назвал прямо минималистичным, учитывая то, что ее прямо позиционируют как альтернативу хранению данных просто в файлах.
Think of SQLite not as a replacement for Oracle but as a replacement for fopen() https://sqlite.org/about.html
Например в браузеры для JavaScript ее так и не смогли встроить - слишком сложно, слишком большая спецификация, короче фиг вам дорогие разработчики, а не sql, храните в json или ключ-значение и не выпендривайтесь. Но у нас есть обертки на js, которые имитируют sql базу поверх json-хранилища. Скорость? Не думайте об этом, это не для вас. Извиняюсь, отвлекся, в свое время знатно с этой истории пригорело как и со многих иных архитектурных решений в веб-разработке.
cat/grep/less - да, но таких узких утилит не так много и они поставляются как часть очень большой и крупной операционной системы.
Но само собой абсолютизм вреден и я не хотел сказать, что успеха добиваются только и исключительно крупные системы и иного не может быть в принципе. Но в большинстве случаев - да.
Согласен, смотря с чем сравнивать. В принципе есть и промежуточные варианты между файлами и sqlite типа gdbm. Но если хочется иметь SQL - вроде ничего легче sqlite нет и запользовать её в проекте на C/C++ весьма несложно.
Скорость? Не думайте об этом, это не для вас.
Если веб приложение по производительности упирается в скорость работы локальной БД - вы уже что-то делаете не так
Классическое наверное да, а если это PWA, которое должно работать без сети?
Ну и плюс так навскидку, по общему пониманию, разница в скорости между нативной sql СУБД даже такой простой как sqlite хранящей данные в двоичном формате и имитирующей ее оберткой поверх json написанной на javascript должна быть просто огромной.
В конце концов свои собственные данные на клиенте браузер хранит именно в sqlite, просто не показывает ее веб-приложениям.
Что не так в ситуации, когда нагруженное веб-приложение упирается в пропускную способность БД?
У вас вообще термина "пропускная способность БД" быть не должно. Все что работает под высокой нагрузкой должно отдавать контент из памяти (кеш), но точно не из внешних ресурсов.
Логично.
А что насчет использования SQLite в памяти, с периодическим сбросом на диск?
Это конечно, но свой memory state это все же больше key-value структура, а хотелось бы SQL, чтобы и условия в запросах и все такое...
Если вы проектируете структуры хранения в памяти, никакой язык запроса просто не нужен.
Плюс транзакции и блокировки, из-за которых даже если вы файл с данными SQLite будете использовать из памяти - это будет все равно слишком медленно.
А как быть с полями неопределенного размера? Поле может быть 0 байт, может быть гигабайт. Выделять для них отдельные буферы?
А физические ресурсы у вас тоже "неопределенного размера"? Память варьируется от 512Кб до 3Тб в пределах одной задачи?
И процессоров - от нуля до миллиона, ага.
Компьютеры тем и хороши (были до нейросетей), что в них не бывает неопределенности, всегда есть предсказуемый лимит.
Если включить голову и подумать, можно легко оценить все возможные размеры и схему хранения, где гигабайты самих данных будут храниться в дисковом массиве, а метаданные и связи - в памяти.
Если вы проектируете структуры хранения в памяти, никакой язык запроса просто не нужен.
Ну почему же, конструкции типа linq и прочие map/reduce местами удобны
Если вы проектируете структуры хранения в памяти, никакой язык запроса просто не нужен.
Эдак любой абстрактор можно объявить ненужным, ибо без него всегда можно как-то обойтись. Вопрос лишь в том, насколько неудобно это будет.
Язык запросов с местом хранения данных никак не связан, он -- про удобство создания этих запросов.
Одно дело, если ваши данные -- один список с одним индексом (или даже без индекса), пусть даже и большой: вы один раз напишете несколько функций для работы с этим списком, и это закроет все возможные сценарии работы с ним, которые у вас могут возникнуть в работе над проектом, использующим эти данные.
Совсем другое дело, если данные имеют сколько-то сложную структуру -- без языка запросов вам придётся писать специальную функцию для каждой ерунды, и вы скоро обнаружите, что только этим и занимаетесь, вместо работы над кодом, реализующим логику обработки этих данных. А уж поддерживать потом этот код... ммм...
Короче, тут диалектика: универсально-правильного решения нет, оптимальное решение нужно выбирать под конкретную задачу. Где-то выгодно одно, где-то совсем другое, без учёта особенностей конкретной задачи сказать, какое решение лучше "вообще", нельзя.
В длинном списке причин из "не знаю, не умею, не хочу, тут это не надо, не буду этого делать" обычно нет самого важного: "мне просто не дадут это сделать в текущем проекте".
Поэтому теоретизировать можно сколь угодно долго, на практике же есть ровно два варианта:
1) вас позвали именно ради оптимизаций и вы применяете все ваши таланты и известные методы оптимизации
2) все остальное
Второе это 99% проектов.
Красивый сайт. Но если убрать к чертям собачьим всю анимацию будет вообще замечательно. На третьем экране сдался и закрыл вкладку.
Сходу приходит на ум sqlite, который без огромного количества фич Oracle или Postgres используется более чем массово.
Не уверен, что вообще корректно сравнивать эти СУБД...
SQLite - это встраиваемая (embedded), в то время как Oracle и Postgres - это полнофункциональные клиент-серверные СУБД. Это абсолютно разные типы баз данных, и требования к ним, и сферы задач, которые они решают, совершенно разные.
Это всё равно, что сравнивать между собой столовую ложку и миксер. Да, можно смешать смесь для выпечки с помощью ложки, а можно с помощью миксера, и это будет намного быстрее — но это же не значит, что ложки отстой, просто они предназначены, в общем-то, для иных целей, чем миксер.
Я же не спорю с тем, что минималистичные и полнофункциональные инструменты применяются для разных вещей (и соответственно востребованы и те и другие в зависимости от применения). Но в данном случае и то и другое позволяет с помощью SQL запросов наполнить базу и потом доставать из неё данные, так что сравнивать вполне можно )
Я хотел сказать, что SQLite и подобные ей встроенные СУБД хоть, как вы говорили выше, не имеют "огромного количества фич Oracle или Postgres", но зато у него (как и у других встраиваемых) есть две очень важные фичи, которых нет у вышеупомянутых СУБД. Это:
простота использования (эту СУБД не требуется устанавливать как отдельный демон, не нужно настраивать, не нужен сервер - работа с ней идёт напрямую через библиотеку в приложении)
переносимость (всё, что нужно, чтобы перенести эту базу на другую машину и даже другую ОС - это скопировать файл, и всё)
То есть, эта СУБД массово используют не вопреки её простоте, а благодаря вышеупомянутым фичам, которыми ни Оракл, ни Постгря похвастаться не могут :)
Чаще сейчас используют миксер, когда хватило бы ложки
И рассказывают, что ресурсов хватит всем, чего вы экономите
Ну, губит или не губит, а портировать условный апач под esp32 ради того, чтоб коробочка-для-мигания-лампочкой могла управляться из браузера -- очевидно, крайне избыточно. Встройкам нужен предельно простой сервер без лишних наворотов
А я просто `python -m http.server 8080` и дело в шляпе :)
А если поинтересней хочется, то даже `pip install uploadserver` и `python -m uploadserver --basic-auth foobar:barfoo 8080`
питон в плане внешней легкости и прототипирования лучший язык. Конечно есть нюанс, что внешне простая либа внутри оказывается чем-то совершенно невменяемым.
У меня на orange pi zero 3 с 512 озушки уже год крутится файлообменник для локалки и даже не для локалки. Именно через питоновский запуск вебстранички. Гоняет через себя сотни гигабайт и хоть бы хны ему - 100 мбит\с вытягивает даже не напрягаясь, по спекам может до 1 гбита, но у меня локаль старого образца. Иногда я даю ему даже задачи типа "перекодировать разрешение фильма для просмотра на умных часах", и он в фоне это крутит, а чего ему будет, 4 ядра на 1,2 это позволяют.
А теперь затащите это на какой нибудь микроконтроллер ;)
Статья фейк, у линуксоида не может быть такой девушки.
Четыре года назад ради интереса написал маленький сервер, который даёт скачивать файлики через браузер.
https://github.com/Kright/files-web-server
В сумме вроде 550 строчек, я про их количество вообще не думал. Что меня впечатлило - в отличие от самбы и прочих штук, за несколько лет использования на домашнем сервере проблем вообще не было и скорость приличная (упирается в скорость локальной сети).
И ещё приятный момент, что написал сам и сам же использую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Маленький веб