LINUX.ORG.RU

Получить данные по сети?

 


0

1

Есть джаваскрипт программа на фронтенде, как бы мне получить данные из базы данных с сервера и желательно на стандартном javascript. Думаю о веб-сокетах, но немного не пойму архитектуру такого подхода, тоже бы желательно понять.

Какие методы получения уже пробовали? Что говорит поисковик? Читали ли man?

Немного не пойму

Лукавите.
Не немного, а сильно.

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

P.S. Как отметили ниже, также непонял, вам для фронта способ нужен или прям код на бэке собрались писать на JS?

mydibyje ★★★
()
Последнее исправление: mydibyje (всего исправлений: 3)

Есть джаваскрипт программа на фронтенде, как бы мне получить данные из базы данных с сервера и желательно на стандартном javascript. Думаю о веб-сокетах, но немного не пойму архитектуру такого подхода, тоже бы желательно понять.

Это называется бэкенд.

goingUp ★★★★★
()

Цитата:

Честно говоря, не вполне понимаю, почему подобную публику постоянно тянет на мой сайт, ну да ладно. В большинстве случаев, конечно, комменты от подобных персонажей остаются в очереди на премод навсегда, но ЭТО… Почтеннейшая публика, оцените незамутнённость мозга, сожранного веб-разработкой до терминальной стадии. Всё-таки не каждый день попадаются столь эталонные образчики.

В общем, попробуем это отпрепарировать. И начнём с вот этого:

(контестная система)

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

Бывшие олимпиадники потом не годятся вообще ни на что, а брать их на работу можно разве что от полной безысходности — вот от безысходности их, собственно, и берут. Программистов жесточайший дефицит, а на безрыбье и рак сойдёт. Между тем, обрести олимпиадность головного мозга проще пареной репы, в большинстве случаев хватает участия в одной олимпиаде; а преодолеть — практически невозможно.

Не нормально, когда пользователь ждет от веб-сервера ответа несколько десятков секунд

Разумеется, ненормально, когда программы обезьяны пишут. Совсем в этом ничего нормального нет. В особенности ненормально, когда сама возможность такого «решения» — не отвечать на запрос, пока у нас там за кулисами не завершится хрень с недетерминированным временем работы — вообще приходит в голову человеку, пытающемуся сваять какую бы то ни было приблуду, оснащённую веб-интерфейсом.

Впрочем, вебщики довольно часто не понимают, как устроен веб. И вообще как хоть что-нибудь в мире устроено. Для уЭбразработки, как известно, никакого понимания не требуется. А что веб усилиями подобных унтерменшей превращён в полное дерьмо — это вопрос уже даже не второй.

Выводы, впрочем, наш персонаж делает ещё интереснее:

Сервер должен ответить «202 Accepted»

Какой ещё в задницу 202? Какое отношение система тестирования имеет к веб-пространству?! И, главное, использовать код результата, который браузеры толком не понимают, как обрабатывать (ибо вообще-то никто не понимает), — вот это во

т зачем? Чтобы что?!

С любым скриптом на стороне клиента, хоть простеньким, хоть сложненьким, можно и нужно получить пинок ногой под рёбра. Потом ещё под дых. И по яйцам. А потом ещё по башке, и снова под рёбра — и ногами, ногами, желательно в берцах. И так до тех пор, пока из очередной поганой мрази не будет полностью выбито желание запускать программы на чужих компьютерах, не спросив сначала двести разрешений.

realbarmaley ★★
()
Последнее исправление: realbarmaley (всего исправлений: 1)

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

Если данные нужно обновлять не когда захочет клиент (при открытии страницы, при нажатии какой-нибудь кнопки пользователем), а когда захочет сервер (например, происходит какое-то событие на сервере и новые данные в ту же секунду отображаются на клиенте), либо если нужно обновлять данные часто (например, каждую секунду, хотя тут спорно, потому что в HTTP 1.1 поддерживается переиспользование одного подключения на много запросов и, вероятно, даже если дёргать fetch каждную секунду особого оверхеда не будет), то лучше подходят веб-сокеты.

В обоих случаях ты не можешь напрямую обращаться к БД, тебе нужен бекэнд. Если ты уже знаешь JS, то проще всего будет сделать бекэнд на Node.js (или на Deno, если любишь стильное модное молодёжное). Он будет принимать запросы от клиента по HTTP/WebSocket и преобразовывать их в запросы к БД, а затем возвращать результат (а также попутно может делать дополнительные преобразования данных и прочую бизнес-логику).

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от bad_master

да как бы не называлось, сделать то как?

Вон выше @KivApple хороший ответ дал. Бери ChatGPT, спрашивай, как отправить запрос через fetch, как сделать хелловордный бекенд на ноде (можно взять фреймворк, например expressjs), как отправить из жаваскрипта запрос в базу, потом заворачиваешь данные в json и готово.

Вебсокеты тут плохо подходят, и это будет в разы сложнее.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от firkax

Браузер не умеет ничего кроме HTTP. А у баз обычно свой ваер протокол. Поэтому без посредника это невозможно, по крайней мере для многих баз.

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

vbr ★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от bad_master

А где 3-е звено, если у тебя только база и фронт? 3-х обычно и делается, чтобы база голой жопой в интернет не торчала и апи был вменяемым, а не sql запросы к таблицам в 3нф.

crutch_master ★★★★★
()
Ответ на: комментарий от bad_master

Вообще я знаю одну такую тузлу которая «решает» вопрос бд с graphql/rest, конструктором сущностей, какой-то там админкой, но я тебе про неё ничего не расскажу, делай лучше нормально фротнэнд->бекенд->база данных, с нормальной схемой данных и нормальным апи.

crutch_master ★★★★★
()

Пишешь серверную программу, которая принимает запрос по http, разбирает переданные параметры, делает нужные запросы в кэш, базу(-ы), еще каким то образом жонглирует данными и отдает ответ клиенту в виде json-объекта. Получаешь классическую трехзвенную архитектуру: клиент <-> сервер приложения <-> субд. Из клиента обращаешься к серверу приложения упомянутым выше fetch(). Можно обмазаться react-ом

cobold ★★★★★
()
Ответ на: комментарий от cobold

Дополню, для прода надо побогаче: клиент <-> вебсокет <-> сервер очереди <-> сервер приложения <-> субд. И чтоб номер очереди стрелял с наносекундной скоростью, иначе блокирующий вызов, кровь, кишки и этсамое.

Anoxemian ★★★★★
()
Ответ на: комментарий от KivApple

переиспользование подключения на много запросов или мультиплексирование начинается с http2. А http1 не только не оптимизирует этот момент, но и в большинстве бравзеров ограничивает количество одновременных соединений к серверу на 2-4шт., т.е. если у вас 20 запросов (включая все статики) и в середине один-два тяжелых остальные будут раздупляться вокруг(после) них

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 1)
Ответ на: комментарий от Dimez

На чём умеешь, на том и делай, что за глупый вопрос то?

Умею на с++, но только не это и примеров не видел в сети работы с http на с++, а по правде не умею ни на чём

bad_master
() автор топика
Последнее исправление: bad_master (всего исправлений: 2)
Ответ на: комментарий от Syncro

Что насчёт connection: keep-alive?

Хотя у меня и без него. Недавно игрался с Rust и hyper. Так вот, Chrome после получения ответа на запрос не закрывает подключение, а переиспользует его. В самом обмене упоминается только HTTP 1.1.

Из-за этого у меня был глюк, потому что я думал, что моя лямбда для обработки запроса в ответ на конннект одноразовая, а она оказалась многоразовая и пришлось это учитывать.

KivApple ★★★★★
()
Ответ на: комментарий от bad_master

Умею на с++, но только не это и примеров не видел в сети работы с http на с++, а по правде не умею ни на чём

Когда мне потребовалось добавить http в свой контроллер компрессорной на С++, я добавил в проект встроенный сервер civetweb и им обрабатываю и статику и динамику.
А вообще можно использовать для статики www-сервер nginx, а динамику генерить, хоть через cgi (например, cgicc), fcgi (fastcgicc), scgi (почитай https://habr.com/ru/articles/111587/)
Сейчас с civetweb переползаю на drogon - https://github.com/drogonframework/drogon

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 1)
Ответ на: комментарий от KivApple

похоже что так да, тогда наверное это лучше делать поллингом, что-бы если один запрос затупит на более одной секунды не заваливать сервер новыми запросами

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 1)
10 ноября 2023 г.
Ответ на: комментарий от bad_master

Если БД - oracle, то есть готовый вариантик, называется oracle EPG. Там почти ничего не надо делать, только активировать EPG и создать PLSQL процедуру в БД.

Если близок C/C++, на нем тоже можно и в http и в ws. Если интересно, дам ссылку на гитхаб с заготовкой на C - принимает соединения от браузера, парсит параметры, отдает статику или приводит в ендпоинты. Есть websocket. Всё многопоточно.

Paka_RD
()