> Ну вот в примере выше, с разными паролями, мне же нужно сообщить клиенту, что данные невалидны и сказать, что именно не так. Чтобы клиент как-то на это отреагировал, например, отобразил ошибку пользователю. Ну то есть я не могу ответить просто 400 BAD REQUEST — нужно конкретизировать ошибку. А ошибку кидает форма и кроме текста ошибки у меня ничего нет.
Так вы же сами говорите, что клиент сам валидирует. Чтобы ограничить себя от ошибок вам достаточно знать, что все введённые поля соотвествуют заявленному формату. Т.е. вы отделяете логику валидации, которую может выполнить клиент, от логики валидации на серверной стороне. Пишете в спеке для тех, кто клиент реализует, что пароль такой-то длины, может содержать от стольки до стольки символов и т.д. Пусть они сами занимаются обработкой этих данных. А на серверной стороне вам достаточно проверить, что переданные данные соотвествуют заявленному формату, А вот если валидация на серверной стороне не выполняется, ну к примеру может быть так, что вам нужно, чтобы как минимум последние три пароля были уникальными, то вы уже возвращаете ошибку и не просто статус 400, а JSON с заранее регламентированным кодом.
Django forms как раз и создавались для удобства валидации в том числе данных из моделек, ну и с возвратом текстовых сообщений для пользователя, с учётом локализации и прочего. Так что в вашем случае они особо и не нужны.
Если django models не используете, то где хранятся данные? Может я что смогу подсказать.
Простите, всё же не понимаю, зачем конкретные данные ошибок из формы? При осуществлении операции вам недостаточно ответа на вопрос валидны ли данные? Ну и если валидны, то пытаемся выполнить операцию, если не валидные возвращаем клиенту статус о невалидности данных.
Ваше решение с локализованными кодами как-то смахивает на костыль.
Еще в последнее время тенденция такова, что числовые коды ошибок уже не являются особо хорошей практикой. Экономия всего несколько байтов, а код invalid_request или processing_error гораздо читабельнее и легче в отладке, не нужно смотреть на 100500 описаний ошибок. Главное чтобы было четко описанное подмножество ошибок.
Ну тогда не вижу проблем. Валидация выполняется на стороне клиента. На сервере достаточно знать прошла валидация или нет. Ну и возвращаете коды ошибок для специфичных случаев данного ресурса. К примеру, имеем регистрацию, пользователь вводит логин, почту, пароль, может еще что-то. Вы проверяете на клиенте, что поля валидные. А когда к примеру занят логин, то возвращаете HTTP статус 400 Bad Request, ну и JSON что-нибудь типа {'error': 1, 'message': 'Login exists.'}. Зачем вам гонять по каналу ненужные сообщени о валидации, они должны быть четко описаны в спецификации к программному интерфейсу. Вам и формы-то не нужны по идее, нужны только валидаторы, если все равно нет HTML морды. Или у вас какие специфичные требования, которых я не понимаю?
Просадка будет в любом случае, но вот насколько при конкретном дизайне приложения — вопрос. Тестить нужно в любом случае. Кластер поднимается легко. Решение в любом случае за вами. Но несколько успешных историй перехода в частности с MongoDB на Riak я слышал. Но у них разная начинка, всё сильно зависит от архитектуры. В вашем случае, если я правильно понял, нужно persistent key-value store, таких много. У меня есть знакомые, которые вообще юзали leveldb напрямую, кстати, надо выяснить насколько успешно.
А я просто не первый раз слышу о проблемах, подобных вашим, поэтому на MongoDB смотрю скептически еще с первого знакомства, когда при выборе горизонтально масшатибируемого NoSQL решения она фейлилась на простых тестовых данных. Тогда были соотвествующие багрепорты, но вроде всё упиралось в архитектуру. И тоже как раз было связано с локами. Вообще решения, которые не могут гарантировать «предсказуемых результатов» при масштабировании трудно назвать ориентированными на highload.
Раз данные у вас так быстро растут, то может быть стоит обратить внимание на решения типа Riak или Voldemort?
Обратите внимание, что Tryton в первую очередь готовый продукт. Есть ряд готовый модулей. Я рекомендую изучить информацию на сайте и попробовать установить, хотя бы клиент для работы с их демо-сервером. Многое станет яснее. А потом уже будете думать.
Интерпретатор конечно же нужен, но его не обязательно ставить отдельно. У Tryton есть готовая инфраструктура для создания экзешников и инсталляторов для Windows. Исходники доступны, можете изучить. Ну и в первую очередь стоить поставить уже собранные бинари и поглядеть насколько это удобно и устраивает ли в таком виде.
Я сам не большой фанат использования Python для разработки GUI-приложений, но в принципе есть только один фактор, который говорит в минус — это используемая память. Учитывая, что память довольно дешевая и на любом даже бюджетном десктопе ее достаточно, то это уже не особо критичный фактор. А если учитывать, что этот специализированный софт будет основным рабочим инструментом, то думаю вообще волноваться не стоит. О скорости думаю переживать не стоит. Но в итоге вам решать, я деталей и масштабов вашего проекта не знаю. Просто предлагаю один из вариантов.
Тогда тем более гляньте на Tryton. Он как раз для этих целей. Для клиентской части там используется GTK. Клиент для Windows есть в разделе Downloads. Вы попробуйте поставить, установить модули необходимые, а потом сделаете выводы. Не очень понимаю на самом деле почему Python не подходит, если фреймворк как раз под ваши нужды.
750 hours of Amazon EC2 Linux† Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month*
* These free tiers are only available to new AWS customers, and are available for 12 months following your AWS sign-up date. When your free usage expires or if your application use exceeds the free usage tiers, you simply pay standard, pay-as-you-go service rates…
Т.е. вам дают 750 часов пользования микроинстансом, все, что выше, будет оплачиваться согласно их тарифам. Ну и по остальным пунктам так же.
Естественно можете создавать, тратить и т.д. Но за все, что свыше Free Tier придется платить. Рекомендую изучить правила предоставления Free Tier подробнее.
Если вы про Interspire, то работал. Я ушел из проекта, но помоему там до сих пор этот движок, он и тогда всем устраивал. Но вообще печально, да. Как я понял проекты они закрывают. Я полагаю им нет смысла заниматься поддержкой self-hosted решений, когда есть много бесплатных и их продукты воруют. Но это лучшее, что было из коммерческих на рынке, очень жаль.
У меня вторая есть на русском, в бумажном виде, если захотите купить, то есть на Озоне — www.ozon.ru/context/detail/id/5637788/. Но я всегда пользовался только оригиналом в электронном виде, так что не могу сказать о качестве перевода. Я бы не рисковал! :)
Так это не мне ответы нужны, а вам, я же специально сделал акцент на том, что это не вопросы! :) А за ответы спасибо!
Добавлю еще на каком основании я делал выводы. Так вот. Задача у вас довольно простая, большинство свистелок вам не нужны. Я сторонник минимализма, поэтому привык брать самое простое надежное решение и доработать слегка.
Я видел, что вы уже сделали выбор, но ответил на случай, если кому-то еще пригодится.
Ну и еще классикой считается серия TCP/IP Illustrated. Я не спец по сетям, поэтому не знаю насколько информация еще актуальна. Знающие люди меня поправят, если что. Думаю должен быть и русский перевод этих книг. К сожалению, из-за часто ужасного перевода предпочитаю оригинал, в любом случае нет смысла серьезно работа в отрасли IT без знания английского.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Так вы же сами говорите, что клиент сам валидирует. Чтобы ограничить себя от ошибок вам достаточно знать, что все введённые поля соотвествуют заявленному формату. Т.е. вы отделяете логику валидации, которую может выполнить клиент, от логики валидации на серверной стороне. Пишете в спеке для тех, кто клиент реализует, что пароль такой-то длины, может содержать от стольки до стольки символов и т.д. Пусть они сами занимаются обработкой этих данных. А на серверной стороне вам достаточно проверить, что переданные данные соотвествуют заявленному формату, А вот если валидация на серверной стороне не выполняется, ну к примеру может быть так, что вам нужно, чтобы как минимум последние три пароля были уникальными, то вы уже возвращаете ошибку и не просто статус 400, а JSON с заранее регламентированным кодом.
Django forms как раз и создавались для удобства валидации в том числе данных из моделек, ну и с возвратом текстовых сообщений для пользователя, с учётом локализации и прочего. Так что в вашем случае они особо и не нужны.
Если django models не используете, то где хранятся данные? Может я что смогу подсказать.