Движок онлайн-сервиса на Lazarus

[Ichthyander]

1. Есть идея сделать сайт. На PHP написать, конечно, можно, но в FreePascal для меня будет на порядки быстрей и проще. Функционал сайта нестандартный (нефорум, непортал, неблог, некий сервис объединяющий множество других с помощью API) и само-собой будет динамический. Хочеться услышать советы и мнения от тех, кто пробовал делать движки сайтов на Lazarus, так как тема для меня новая и хочется заранее знать о подводных камнях и в каком направлении лучше сразу смотреть.
Предварительно думаю реализовать его как cgi приложение под Linux. Достаточно будет десктопной версии Ubuntu/Debian для тестирования приложения?
Сайт не должен быть особо трафиковым (думаю не больше 100 уников в сутки), но будет предоставлять услуги авторизованным пользователям сервиса.
2. Есть также идея попробовать к моему существующему трафиковому (относительно) сайту (2000-3000 уников до 10тыс.просмотров) приделать дополнительный расчетный сервис (не очень сложные расчеты, можно даже обойтись без использования базы данных одним кешом). Судя по тому, что я успел изучить по топикам на этом форуме это будет не очень хорошая идея, так как на каждую сессию будет запускаться отдельный процесс. С другой стороны у меня на моем немецком VPS несколько десятков сайтов с CMS типа Joomla порой даже без кеширования и ничего, все нормально держит. Что думаете?
Спасибо заранее за ответы. Хочеться услышать рекомендации, советы, возможно полезные примеры на Lazarus

[скалогрыз]

Функционал сайта нестандартный (нефорум, непортал, неблог, некий сервис объединяющий множество других с помощью API) и само-собой будет динамический. Хочеться услышать советы и мнения от тех, кто пробовал делать движки сайтов на Lazarus, так как тема для меня новая и хочется заранее знать о подводных камнях и в каком направлении лучше сразу смотреть.

имхо, лучше сначала определится с функционалом сайта... и использовать уже готовый движок, и самому ничего не писать

Предварительно думаю реализовать его как cgi приложение под Linux. Достаточно будет десктопной версии Ubuntu/Debian для тестирования приложения?

декстопная версия тебе как раз не нужна. тебе нужна консольная версия.

[Ichthyander]

имхо, лучше сначала определится с функционалом сайта... и использовать уже готовый движок, и самому ничего не писать

Хм.. Я сам за использование готовых решений. Но вся соль проекта в узкой специализации. Движков под такое нет. Ну разве что, использовать популярную CMS как обертку, но в этом нет проблем и вопросов. Меня интересует начинка основного функционала сайта, которого в готовом или сыром виде нет в платном или открытом коде. Есть мои наработки в десктопных программах в Lazarus, которые я в принципе и мог бы использовать для портирования в серверную версию

декстопная версия тебе как раз не нужна. тебе нужна консольная версия.

Ну а я смогу собирать cgi приложение в десктопной версии и заливать на свой сервер для теста? Хотя я думал, что можно будет как-то настроить десктоп и тестить на нем Linux-серверные приложения: что-нибудь вроде Денвера для Windows...

[SSerge]

ля меня будет на порядки быстрей и проще.

Результат со временем сведется к тому, что любые изменения на порядки быстрее и проще вносить в код php, чем в паскалевский. Особенно, когда уже забыл о всех тонкостях и взаимосвязях и то, как все запрограммировано. Кроме того нет паразитной ступени в виде необходимости это всё сначала компилировать, а потом на сайт копировать

не очень сложные расчеты

Смотря какие расчеты. Прелесть в том, что если программа в результате каких либо некорректных данных или программирования зациклится, то cgi процесс навсегда повиснет в памяти, причем в активном виде, с потреблением ресурсов, в отличие от потока php, который будет сервером снят в среднем секунд через 30 (по настройкам). С десяток таких зомби - и сервер ляжет. Т.е., чтобы этого не происходило, нужно предельно внимательно контролировать и данные и алгоритмику. А потому - jeden das seine. Расчётные программы под cgi - очень плохая идея с точки зрения устойчивости их работы и ресурсоёмкости

[Ichthyander]

ля меня будет на порядки быстрей и проще.

Результат со временем сведется к тому, что любые изменения на порядки быстрее и проще вносить в код php, чем в паскалевский. Особенно, когда уже забыл о всех тонкостях и взаимосвязях и то, как все запрограммировано. Кроме того нет паразитной ступени в виде необходимости это всё сначала компилировать, а потом на сайт копировать

Почему? Я спокойно вношу изменения в свой код в программах. И для меня он более читабельный, чем скажем код на PHP, просто потому что в PHP на порядок меньше опыта. В компиляции проблем не вижу

не очень сложные расчеты

Смотря какие расчеты. Прелесть в том, что если программа в результате каких либо некорректных данных или программирования зациклится, то cgi процесс навсегда повиснет в памяти, причем в активном виде, с потреблением ресурсов, в отличие от потока php, который будет сервером снят в среднем секунд через 30 (по настройкам). С десяток таких зомби - и сервер ляжет. Т.е., чтобы этого не происходило, нужно предельно внимательно контролировать и данные и алгоритмику. А потому - jeden das seine. Расчётные программы под cgi - очень плохая идея с точки зрения устойчивости их работы и ресурсоёмкости

Про такое читал на этом форуме. В принципе согласен. Я конечно не могу назвать себя супер-профессионалом в программировании, но тем не менее такое с моими прогами случается редко... Вылетать-вылетают конечно программы, могут быть неэффективными, а вот зацикливание (не сглазить), даже не могу припомнить. Но мысль понятна и это действительно значительный минус.
По поводу утойчивости понятно. По поводу ресурсоемкости почему могут быть проблемы, при условии, что программа будет написано правильно и аккуратно (а это мне на FreePascal сделать будет проще)

Добавлено спустя 1 минуту 45 секунд:
Да и кстати про один из плюсов (может я чего-то не понимаю): по идее cgi-приложение сломать сложней, чем любой другой скриптовое приложение, ведь доступ к исходному коду ограничен по определению?
Да, и специфика проекта №1 такова, что несанкционированный доступ на порядки опасней, чем падения сервера. А вот специфика проекта №2 с расчетной утилитой безопасность не важна, так как она не будет завязана с деньгами пользователей, но трафик там большой

[SSerge]

о идее cgi-приложение сломать сложней

Дырок в программировании GET/POST запросов номинально больше, чем для подобных интерфейсов для php, особенно если CGI интерфейс программируешь самостоятельно. Да и в готовых библиотеках могут быть дыры - всё потому что не массовая и не популярная технология.

вот зацикливание (не сглазить), даже не могу припомнить.

Я и говорю - смотря какие расчеты. Иногда это означает многочисленные итерации и возвраты с целью автоматической коррекции данных - вот и зацикливание.

Да, кстати, сессионность то тоже писать придётся руками.
И каки прожить - руками.

...не вижу никаких преимуществ.

[grot]

nginx + TFPHTTPServer (find an example how to setup a linux diemon)

[SSerge]

Да, кстати, для CGI недоступно много чего, оказывающего косвенное влияние на функционирование прграмм FPC: навскидку - программа, например, не в состоянии определить текущую локаль системы (полезут косяки со строками с кириллицей, особенно в 3.х компиляторах), у нее права доступа такие же как у сервера Apache - а это обычно пораженный в правах процесс. Переменные окружения тоже недоступны. Недоступна часть информации, которая легко и само собой получается кодом PHP, и в целом процесс передачи потока на CGI медленнее, чем встроенному модулю - хотя, это уже для фанатов.

Добавлено спустя 2 минуты 44 секунды:
А, ну да! Таки пока видимо одно преимущество - исходник наглухо спрятан от хостера сервера, и он не сумеет покрасть твой код!

[Ichthyander]

nginx + TFPHTTPServer (find an example how to setup a linux diemon)

Ну, у меня нет цели писать веб-сервер вообще вместо апач. Апач вполне устраивает. Возможно даже буду использовать CMS на PHP как обертку, да и другие сайты есть на сервере.

Добавлено спустя 5 минут 48 секунд:

Да, кстати, для CGI недоступно много чего, оказывающего косвенное влияние на функционирование прграмм FPC: навскидку - программа, например, не в состоянии определить текущую локаль системы (полезут косяки со строками с кириллицей, особенно в 3.х компиляторах), у нее права доступа такие же как у сервера Apache - а это обычно пораженный в правах процесс. Переменные окружения тоже недоступны. Недоступна часть информации, которая легко и само собой получается кодом PHP, и в целом процесс передачи потока на CGI медленнее, чем встроенному модулю - хотя, это уже для фанатов.

Ну всякие системные переменные, определение локали и прочее мне не понадобится. Будет взаимодействие с пользователем, базой данных (можно даже без нее) с другими сторонними онлайн-сервисами. Так что это не проблема тоже. По поводу медленности, может окажется проблемой для проекта №2. В проекте №1 с этим думаю все ok.

Добавлено спустя 2 минуты 44 секунды:
А, ну да! Таки пока видимо одно преимущество - исходник наглухо спрятан от хостера сервера, и он не сумеет покрасть твой код!

Немаловажно. Есть еще преимущества того же рода. В случае взлома сервера/сайта максимум, код также будет наглухо спрятан... Ну, почти. И еще, приложение можно будет продавать, не боясь расползания кода и воровство идей левыми кодерами

[Лекс Айрин]

вообще-то взлом CGI, если я помню, даже легче чем PHP/HTML. Минус веб-технологий как таковых, в разрозненности -- каждая следующая затыкает потребности других, не всегда, кстати, точно. Да и результатом любых махинаций на сервере будет выхлоп страницы в html (или ее части). Ну и клиентская часть всегда доступна для изучения -- скрипты, запросы, обработчики... А в случае ошибки в конфигурации можно вообще выпасть в каталог сайта -- тогда любой ламер сможет скопировать все. (возможно кроме БД) Несколько раз я сам так случайно попадал из поисковика.

[pupsik]

которого в готовом или сыром виде нет в платном или открытом коде

http://www.fastplaz.com/#, http://silvioprog.github.io/brookframework/ и т.д., не подходят под "сырой" вид?

... скрипты, запросы, обработчики... А в случае ошибки в конфигурации можно вообще выпасть...

если я не ошибаюсь: это касаемо любого сайта, сервиса.

[azsx]

Будет взаимодействие с пользователем, базой данных (можно даже без нее) с другими сторонними онлайн-сервисами. Так что это не проблема тоже.

php подходит идеально.
---
вообще интересно иное, в каких случаях cgi на freepascal имеет преимущества перед php. Как я понимаю первым и главным преимуществом является объемный алгоритм расчета. То есть если алгоритм на 15 тысяч строчк кода, то логичнее его не писать на php. Или есть какие то иные преимущества?

[скалогрыз]

Или есть какие то иные преимущества?

наличие опыта в разработке и необходимых библиотек.

на самом деле, ничто не мешает держать паскаль на сервере на уровне "скрипта". Т.е. компилировать исходники прямо на сервере. Т.е. поступил запрос в cgi, он сначала проверит "не поменялись ли исходники", если да, то попробует их скомпилировать.

Вся крутизна в скорости компиляции паскаля Если поменялся один-два модуля, программа пересоберёться очень быстро.

Во времена делфи такое не прокатило бы. Ибо лицензия делфи запрещает распространение самого делфи, как компилятора. А вот на FPC такого ограничения нет. И такое его использование не противоречит GPL лицензии

[Лекс Айрин]

если я не ошибаюсь: это касаемо любого сайта, сервиса.

о да. В идеале, должна выкидываться страница с ошибкой 404 (возможно и некоторые другие)

[Ichthyander]

которого в готовом или сыром виде нет в платном или открытом коде

http://www.fastplaz.com/#, http://silvioprog.github.io/brookframework/ и т.д., не подходят под "сырой" вид?

... скрипты, запросы, обработчики... А в случае ошибки в конфигурации можно вообще выпасть...

если я не ошибаюсь: это касаемо любого сайта, сервиса.

Я имел ввиду готовых решений на PHP. Хотя за ссылки большое спасибо! Впервые слышу о таких фреймворках на FreePascal. Изучу эту тему. Сами, кстати, не пробовали?

Добавлено спустя 2 минуты 48 секунд:

php подходит идеально.
---
вообще интересно иное, в каких случаях cgi на freepascal имеет преимущества перед php. Как я понимаю первым и главным преимуществом является объемный алгоритм расчета. То есть если алгоритм на 15 тысяч строчк кода, то логичнее его не писать на php. Или есть какие то иные преимущества?

Ну, кроме взаимодействия нужно будет еще реализовать алгоритм работы сервиса, в котором я вся соль так сказать. Для меня является большим преимуществом, что относительно сложные приложения на PHP я не реализовывал, в основном доработка и небольшие скрипты. А также то, что исходный код программы не своруют просто так.

Добавлено спустя 6 минут 1 секунду:

вообще-то взлом CGI, если я помню, даже легче чем PHP/HTML. Минус веб-технологий как таковых, в разрозненности -- каждая следующая затыкает потребности других, не всегда, кстати, точно. Да и результатом любых махинаций на сервере будет выхлоп страницы в html (или ее части). Ну и клиентская часть всегда доступна для изучения -- скрипты, запросы, обработчики... А в случае ошибки в конфигурации можно вообще выпасть в каталог сайта -- тогда любой ламер сможет скопировать все. (возможно кроме БД) Несколько раз я сам так случайно попадал из поисковика.

Да нет, приложение "сломать" не получится. К тому, чтобы его "принудить" выдать содержимое папки? На PHP это представляю. Даже представляю чем грозит то, что если злоумышленник получить хотя бы доступ к чтению к какой-либо папки со скриптами. Но скрипты обеспечат максимум функцию обертки, а вообще, можно только cgi обойтись. В случае CGI приложение он максимум сможет прочесть набор данных исполняемого модуля. Реинжиниринг гораздо сложнее в этом случае. По поводу безопасности все-таки не согласен... Мне кажется тут есть большие преимущества именно исполняемых модулем, чем скриптов...