Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Серверная часть на NodeJS.Что, Как, Когда?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всем привет. Хотелось бы узнать профессиональное мнение по поводу последовательности действий при проектировании серверной части приложения+связи ее с клиентом(желательно на примере NodeJs+socket).

Что делать в 1 очередь? Как продумать правильную структуру классов(модулей)? Начинать привязывать сразу к клиенту или сделать полную версию backend и только после этого вязать к клиенту? Как тестировать нагрузку на серверную часть?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Почему всплыл этот топик?

Микросервисы предполагают изоляцию баз данных. То есть на каждый сервис по базе данных.

Что делать в 1 очередь?

Самое важное, что вам надо сделать, это запустить ваш сервак и удалить с него нод и больше никогда не прикасацца к этому поделию. А то волосы на ладошках вырастут. Бонус, если вместо этого исчадия ада поставите лисп, питон или руби.

Как продумать правильную структуру классов(модулей)?

Ну как в классике, выделяете сущности, определяете поведение, проводите декомпозицию, пишете первую версию интерфейса, много удмаете, переписываете, чтобы стало удобнее.

Начинать привязывать сразу к клиенту или сделать полную версию backend и только после этого вязать к клиенту?

Я бы делал параллльную интеграцию. Легче увидеть недосмотры при проектировании, чтобы поднять удобство.

Как тестировать нагрузку на серверную часть?

Берете и тестируете с помощью каких-нить рутин. Если сильно хоцца, пишете тесты на каком-нить нативно живеньком езыке, типа Go и начинаете с разных серрваков колбасить коннекты. Вот и все.

удалить с него нод и больше никогда не прикасацца к этому подели
благодарю за конструктивную критику!
Берете и тестируете с помощью каких-нить рутин.
тоже четенький ответ!

Палыч, вы два раза процитировали одно и то же. Нода головного мозга?

поздно вы реагируете — я уже исправил)

поздно вы реагируете — я уже исправил)

Пезразницы. Ведь мы оба-то знаем, чо там было.

А ответ дийсно четенький. Ну если подумать, что горутины — часть языка го.

Нода вас поглощает. БЕгите на любой нормальный (т.е. не жаба с шарпом) язык. А то скоро заикацца начнете, а там и до какацца недалеко.

спасибо за ответ! надеюсь вас в вашей компании все понимают и ценят за такие конструктивные и понятные советы)

надеюсь вас в вашей компании все понимают и ценят за такие конструктивные и понятные советы)

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

З.Ы. Конкретно в моей, да — ценят. А иначе руки поотрываю.

лучше всего наверное начинать с фреймворков а-ля express.js/koa.js и подобных (есть еще любопытный фреймворк total.js).
для связи с клиентом вроде как есть разные модули под того же ангкуляр или бэкбон для связки их с различными нодовскими фреймворками.
p.s. в качестве шаблонизатора посоветовал бы jade наверное.

В качестве фреймворка могу порекомендовать koajs.com

Что делать в 1 очередь? Как продумать правильную структуру классов(модулей)? Начинать привязывать сразу к клиенту или сделать полную версию backend и только после этого вязать к клиенту?

эм... ну тут как бэ до ноды саму теорию OOA&D и прочее читать в первую очередь ;)

если коротко: программирование на ноде — исключительно асинхронное, в первую очередь вы должны думать промисами, ивентами и колбеками, но это в общем. В частностях же:
1. нода — 70% правильного (имхо) кода,- даже не всякие там q, async и прочие, а конечные автоматы и состояния, а посему machina-js.org и/или github.com/fschaefer/Stately.js . Здесь главное понимать, что теперь внутреннее интерфейсное API вашего сервисного уровня не вызовы методов, а состояния и переходы между ними. Это для более-менее серьёзной серверной логики, но отображает правильный подход к кодингу асинхронных систем.

2. вы въедете в ноду только после прочтения этих двух книжек:
— www.amazon.com/...io-Casciaro/dp/1783287314
— www.amazon.com/gp/product/1937785270
— и по вкусу из СЕРПа: www.google.com/...nchronous design patterns

3. Рекомендую не юзать официальную ноду, а сразу iojs.org/en/index.html
Правда, писать

class MyChild extends MyParent {
    constructor(one, two, three) {
        super(one, two);

        this.three = three;
    }
}
на порядок доставляет больше, чем что-либо из около 12-и классических способов наследования в до ES6 яваскрипте ;)
желательно на примере NodeJs+socket
юзайте фреймвёрк ;) тот же sailsjs.org/# из коробки например ;)

зы: разумеется, если рассматривать ноду чисто как CRUD бэкэнд для простенькой вебмордочки, то всякие FSM — лишнее, но вопрос, имхо, подразумевал матчасть по более глубоким понятиям проектирования асинхронных архитектур вообще.

огромное спасибо за литературу!

если рассматривать ноду чисто как CRUD бэкэнд для простенькой вебмордочки
вопрос касается чисто пэт проекта.понятно что говнкод может норм работать но «для показа работодателям не рекомендуется»)))

Вроде ж “io.js Will Be Merging Back into Node.js”

угу, но там главное не как они называться будут, а ES6 нативно, без всяких babeljs.io

As a first step, we will move from iojs organization to nodejs organization and will converge joyent/node gradually. We will continue to release io.js until the convergence have done.

Частично ES6 реализован под флагом —harmony в ноде. Например, arrow functions, generators etc

1. Наверно тупой вопрос — а почему NodeJS в качестве технологии для бекенда?
2. Любой популярный фреймворк на NodeJS уже содержит определённую логику которая поможет организовать структуру, модульность и т.д. В интернете куча статьей по этому поводу. Тут наверно еще и возникает вопрос — а как вообще правильно спроектировать API.

да получается что ключевой вопрос тут про апи, а нод идет в дополнение)

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

Если надо просто налепить прототип, то вполне возможно вас устроит Meteor.js или что-то подобное, где даже работа с сокетами упрощена до нельзя.

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

спасибо за ответ. не подскажите литературку где доходчиво объясняется

нужна ли вам кластеризация, масштабирование
проект — игра. планирую реализацию для большого колва посетителей. читал гдето что нативный nodejs лучше для таких моментов
спасибо за ответ. не подскажите литературку где доходчиво объясняется
Лично я не сторонник литературки, т.к. оная по большей части содержит устаревшую информацию. Обычно действую путем — делать proof of concept, наступать на грабли, искать решения на stackoverflow, и смотреть как оно себя ведет.

Например, по грубым оценкам, в 20-ядерную машинку на диджиталоушене примерно можно «вместить» 2 млн одновременно открытых вебсокетов. Соответственно если такого достаточно, то можно ограничиться одной физической машиной и остановиться на обычном нодовском модуле кластер + слать месаджи между воркерами. Если нет, или планируется пользовать несколько менее мощных машин, то стоит в архитектуру включить какой-нибудь MQ для обемна сообщениями между пользователями, которые находятся на разных физических серверах и её же можно использовать для связи вебсокетов на одной и той же машине.

Могу разве что порекомендовать посмотреть доклад Тимура: www.slideshare.net/...dinov/nodejs-architecture. Думаю, что пару ответов на свои вопросы вы там найдёте.

Лучше взять не голую ноду, а какой то стек/фреймворк над ней, и в нем обнычно будут примеры и доки как что называть и куда ложить. Лично мне импонирует mean stack learn.mean.io/...-packages-files-structure

спасибо большое изучу на досуге)

Я думаю, если начал делать API используя фреймворк, оно само как-то организуется в модули. На крайний случай найти пример от разработчиков одного из (www.quora.com/...or-building-a-RESTful-API ).
По поводу, что раньше делать — я обычно делаю одну модель (минимально) на беке, потом сразу на фронте, а потом довожу до ума. Но это мое скромное мнение.

А вообще на quora обсуждалось:
www.quora.com/...lopment-which-comes-first
www.quora.com/...n-do-you-implement-the-UI

да у меня тоже не понятки в голове.так как учу его(нод) сам соответственно не знаю когда лучше написать один app.js а когда 100500 модулей аля ооп)спасибо за ссыль но это кажется http а я хочу юзать сокеты

Спасибо за четкий понятный и исчерпывающий ответ!

Спасибо за четкий понятный и исчерпывающий ответ!
К сожалению, ответ таки исчерпывающий и должен быть понятным. Ваш вопрос не имеет отношения к ноде и эквивалентен такому: Как написать программу?
Тут есть 100500 разный способов, и кажды из них верен в определенном случае. Пока вы не уточните чего хотите вряд ли услышите четкий и исчерпывающий ответ.

проблема заключается в том что я изучаю технологию нода самостоятельно. в книжках которые я читаю по ноду ведутся рассказы как подключиться к бд или как написать асинхронный обработчик — но не слова про архитектуру как таковую. я задал вопрос чтобы как раз таки и понять что мне конкретно нужно почитать(ознакомиться) для того чтобы сделать норм апи. прошу помощи у специалистов не только по ноду так как знаю что принципы для всех языков одни — разный только синтаксис. возможно вы направите меня куда надо)

почитать(ознакомиться) для того чтобы сделать норм апи
Для старта (если речь идет про веб):
martinfowler.com/tags/API design.html
martinfowler.com/...hardsonMaturityModel.html
martinfowler.com/books/eaa.html
www.amazon.com/...-Richardson/dp/0596529260

Підписатись на коментарі