Сообщение от moka
Ой. Ты совсем не туда "пошел".
Во первых - асинхронное программирование, это концепт который ты видимо пока не понял.
Суть заключается в том что у тебя есть только один поток выполнения кода. И есть асинхронный паттерн, где ты типо говоришь: сделай А и когда будет готов ответ, вызови функцию Б.
Таким образом естественно у тебя два вызова и ответ на запрос будут обработаны сразу один за другим, не дожидаясь callback'ов.
Это не PHP, где каждый вызов блокируется - что на самом деле очень плохо.
|
С асинхроном у меня плохо, согласен. Пользовался им только для Ajax и то в простой форме - запрос сделали, потом когда то пришёл ответ и отреагировали асинхронно на него.
Сообщение от moka
Во первых делать API запросы которые возвращают много разной информации - очень плохо.
Лучше сделать два запроса. Таким образом в разных частях кода, когда тебе нужны будут первые или вторые данные, ты сможешь использовать уже имеющийся API route.
|
Собственно сейчас уже "временно" так и сделал - два отдельных API-запроса. Но тут дело в том, что эти два вызова связаны (вывод списка пользователей не возможен без вывода списка групп), поэтому и хотел сразу в одном запросе получиться все данные.
Сообщение от moka
Пару советов по дизайну API:
1. Запросы должны быть конкретными и простыми.
2. Любой запрос должен выдавать нормальные ошибки и учитывать возможность не валидных данных от клиента.
3. Консистентный формат ответа - также помогает упростить реализацию API и клиента.
|
1. Все запросы стараюсь делать конкретными (кроме этого как раз), да. За основу для себя взял список API Вконтакте, так как все его API-запросы соответствуют моим (friends.get, friends.add, user.signup, user.auth, friends.search и т.д.). Они довольно прозрачны.
2. Это прям сразу реализовал, до этого вёл довольно "крупный" проект по размещению данных в социальные сети (работал в рекламном агенстве, для чего писалось своё API над разными API социальных сетей (facebook, twitter, instagram, vk.com, livejournal) и целых ботов для некоторых соц.сетей (мой мир, одноклассники, google+). Поэтому ошибки которые были допущены там стараюсь не повторять и сразу предугадывать.
3. Это тоже стараюсь делать сразу, все ответы сводятся к JSON-массиву обязательно выглядящему либо так (отправляются запрошенные данные):
{
data: {
type: 0,
code: 02,
...
},
error: null
}
либо так (отправляется ошибка)
{
data: null,
error: {
code: 123,
msg: ...
}
}
Сообщение от moka
Также лучше использовать численные ID, нежели ObjectID, т.к. они слишком большие и с ними геморойнее работать.
|
В таком случае надо их генерировать самому? Просто не копал в эту сторону пока что, использовал что есть. ObjectID на данный момент мне не понравились своей нечитабельностью.
Сообщение от moka
Также тебе нужно позаботиться в будущем о pagination - страницы, для infinite scrolling или просто системы страниц, т.к. если у кого-то слишком много друзей, грузить один большой список - это может быть не слишком хорошо.
|
Вот собственно и хотел после "перевода" сервера (с PHP+MySQL на node.js+mongodb, благо реализовано пока что всего 15 только самых нужных API, реализую их постепенно по мере модификации грубого наброска веб-чатика для первой версии сервера) заняться pagination, потому что с проблемой её отсутствия уже сталкивался при первом подходе к чату.
Сообщение от moka
ИМХО, ты опять спешишь, и забегаешь слишком вперед.
Старайся начинать с более простых примеров и задачек, и экспериментов.
|
Вот прям в точку. Просто хочется (мне самому от себя) чтоб было сделано ещё вчера, поэтому спешу, лечу и пропускаю повороты. Из за этого часто возвращаюсь назад. Есть такая проблема у меня, трудно с этим спорить. Борюсь с ней потихоньку
. Дело ещё и в том, что на пыхе всё что нужно на данном этапе могу реализовать сходу, а вот на js "влоб" не получается. Языки то, по сути и подходу к ним - разные. И как бы получается что "я хочу, я могу, я умею, но не этой отвёрткой и не этот шуруп". Не сошлось, короче
. Ну это ничего, свыкнусь, освоюсь.
За код спасибо, он для меня местами выглядит страшно, но вполне читаемо и понятно. Меня прёт в "реляционность", хоть тресни. Ещё не освоился с удобствами монги, поэтому сделал отдельную коллекцию friends со связками (users связаны с users в отношении многие-ко-многим через коллекцию friends), заместо того, чтобы хранить список id друзей у самого пользователя. Меня несёт не туда, а нода и монга попутно ещё и ломают мои взгляды на программирование в целом
.