• Как реализовать POST или GET запросы на vk api через javascript & jquery?

    ixon
    @ixon Автор вопроса
    
    var req="https://api.vk.com/method/users.get?access_token=СекретныйТокен"
    $.ajax({
        url : req,
        type : "GET",
        dataType : "jsonp",
        success : function(msg){
    		console.log(msg.response[0]);
        }
    });
    Ответ написан
    Комментировать
  • Node.js в качестве server-side для enterprise приложения?

    Stdit
    @Stdit
    По моему опыту, nodejs — удобная, стабильная и быстрая штука, имеющая отличное сообщество и много хороших библиотек в npm. Преимущества можно перечислять долго, лучше сразу перейти к проблемам.

    — Сложно найти готовых к работе толковых программистов, даже среди фронтендщиков. Но можно обучить. На обучение и понимание среды nodejs, API, асинхронности, замыканий, калбэков, событий, функционального подхода — уходит примерно месяц-два.
    — Библиотеки из форнтендов использовать можно, но только если они грамотно написаны и оптимизированы для перманентной работы. Иначе есть риск, что они сожрут всю память или повесятся.
    — Сервер nodejs обычно однопоточный, со всеми вытекающими. Имеется возможность форкать и открывать дочерные процессы, на это нужны дополнительные затраты труда. Но это требуется только в исключительных случаях.
    — Код пишется в основном легко, если следовать чёткому стандарту, который обычно навязывается используемым фреймворком. Однако javascript, ввиду своей нестрогости, неустойчив к коррозии, в спешке или по неопытности можно наделать рака и превратить жизнь своей команды в ад.
    — При сложной логике со множеством вызовов можно без злого умысла нагородить «лестниц» из калбеков. Однако, проблема решается разными вариантами библиотек управления задачами (async, Q, и т.д.). Вообще лучше делать максимальную декомпозицию кода, создавать бесчисленные функции внутри функций — не очень хорошая практика.

    По поводу камней:
    — Обычно, всякие руководства и мануалы типа «hello world» используют один сокет для соединения с БД. На практике оказалось, что если этот сокет зависает под тяжёлым запросом, то все остальные запросы прилежно ждут его освобождения. Поэтому первое, что нужно сделать в новом проекте — это подключить database connection pool.
    — Случилось так, что количество одновременных подключений к серверу перевалило за тысячу, и внезапно возникли необъяснимые аномалии и отказы. Как выяснилось, страшного ничего не произошло, и нужно было просто в операционной системе разрешить открывать на порядок больше файловых/сокетных дескрипторов.
    — Память для nodejs лучше ограничивать ключами запуска и отдавать больше для БД (если они на одной машине). В противном случае nodejs не спешит запусктать сборщик мусора (это ведь затратная операция) и разрастается.
    — Перезагрузки nodejs из-за внезапных падений от багов решаются специальными библиотеками, например forever.
    — Чтобы nodejs не вылетал из-за исключений, нужно ставить глобальный обработчик uncaughtException, который пишет их в лог или сразу шлёт на мыло ответственному лицу.
    — Нужно не забывать отвязыватсь обработчики от событий по окончании работы подписанного на событие объекта (removeListener()).

    По поводу фреймворков, используем express, потому что он красивый, простой и мы к нему привыкли.
    Ответ написан
    2 комментария
  • Node.js в качестве server-side для enterprise приложения?

    hell0w0rd
    @hell0w0rd
    Просто разработчик
    tech.yandex.ru/events/yasubbotnik/ekb-jul-2013/talks/970/ — советую посмотреть вот этот доклад и поискать прочие доклады по nodejs с яндекс-субботников. auto и sport у яндекса как раз на ноде
    Ответ написан
    Комментировать
  • Node.js в качестве server-side для enterprise приложения?

    Расскажу свою историю. Раньше моим идеалом приложения было — толстый фронтенд + тяжелые WCF(asp.net) сервисы. Мы как порядочные разработчики и свой фронтэндовый фрэймворк создали. И радовались до тех пора пока не получили заманчивый заказ, но одним из условий — некоторые клиенты с выключенным javascript. Возвращаться к asp.net mvc не хотелось, так и пришло знакомство с нодой. Переделали немного фронтенд фрэймворк, и теперь все компоненты летают и там, и там. И что интересно, можем ограничивать компонент только фронтэндом, или если он манипулирует важными моделями — то только бэкенд. Ещё хорошим открытием стал для нас iisnode модуль — о всех кластерах ноды, логированиe, рестартаx (или падениях ноды) нам даже не нужно беспокоится, и плюс все работает параллельно с WCF сервисами. Вообщем мы пока что рады как слоны)
    Ответ написан
    Комментировать