Тесты можно писать бесконечно, это опять же зависит от требований заказчика и сроков. Можно проверить отправку невалидного JSON-а, отправку запросов с некорректным HTTP методом: GET, POST, HEAD, PATCH... и т. д.
Интересный кейс, а можно продолжить список "и т.д."?)
Все возможные кейсы вручную не проверяют, обычно ограничиваются только критичными случаями (проверяют обязательные поля и пограничные значения для наиболее важных параметров).
а по какому принципу можно выделить "важные" поля?
Леха Ярков: а если у нас не просто 3 поля, а что-то сложнее? Что-то вроде 20 полей, некоторые из которых содержат в себе еще больше полей, некоторые из которых содержат в себе... примерная вложенность 3-4, а объектов таких десятки, а то и сотни тысяч.
Леха Ярков: представьте, что к вам каждую минуту приходит объект с 3 заранее известными полями, к которым вы обращаетесь как к словарю (т.е. object['field1']). Теперь представьте, что к этим трем полям добавили четвертой, имя которого вам неизвестно. Как к нему обратиться?
Леха Ярков: JSON.parse просто переводит из string в объект, а дальше я уже сам считываю поля из объекта и добавляю нужное в базу. Мне же данные нужно не только распарсить и забыть, но и сделать что-то с ними.
PS Понятно, что программа сама не будет знать, что делать с новыми полями. Мне хоты бы обнаруживать их как-то, желательно не сильно влияя на общую производительность.
Константин Китманов: но тогда появляется ряд проблем (т.к. эти скрипты запускаются "по отдельности") (от того, что сторонний сервер (API) может забанить за слишком частые обращения (и тогда надо увеличить время между обращениями) до обращения к базе данных (в node я использую готовый модуль из npm, как его в обычном js использовать?).
oia: я всё прекрасно понимаю и не прошу однозначно точного ответа (факторов тут миллион), но цифра на сайте cpubenchmark мне не говорит вообще ни о чем и нужен более тривиальный пример для более четкого понимания.
oia: еще у меня была мысль запустить на атоме парсер этой информации, а на более мощном уже сам сайт и базу с ElasticSearchem. Что на счет этого скажете?
oia: но все таки, как более комплексно оценить необходимость более мощного процессора? Ну вот например захочу я не большой сайт запустить и будет он скажем на WordPress с обычными статьями и картинками. До скольки хостов выдержит конфигурация с атомом?
oia: основной сложностью является обработка большого количества JSON данных (50-100 ГБ в сутки) с дальнейшим добавлением всего этого в базу ElasticSearch. JSON парсится и в базу добавляются в основном цифровые значения, т.е. информации там во много тысяч, а то и десятков тысяч раз меньше. Но в целом различных значений все равно миллионы, но это всего лишь цифровые значения. Естественно потом по всей этой информации осуществляется поиск.
а не могли бы вы кого нибудь посоветовать адекватного? Основной трафик пока не знаю откуда будет, хотя в начале буду в обе стороны пытаться развиваться.
Это было написано лишь для понимания того что я не могу просто взять и арендовать какой нибудь AWS и не париться. Ясное дело что самому хостеру это вообще не интересно. Помимо этих самых 50-100 ГБ в сутки будут так же и пользователи в любом случае, т.е. в итоге то еще больше данных.
Ну дак это же неправильно, сколько может быть заказчиков в месяц? Может же и все 10+ быть, сколько таких со временем накопится? Поддержка и постоянный присмотр - это уже сис. админ какой то.
lazard105: отправляя такой коммент я предполагал, что раньше гугл даже представить себе не мог на столько ненормальных производителей. Возможно, в версиях выше гугл ставит определенные условия соответствия, по этому и спросил. Он не может не ставить, по тому что это ****.
Интересный кейс, а можно продолжить список "и т.д."?)
а по какому принципу можно выделить "важные" поля?
Спасибо за ответ!