Onko helpompaa web server:iä kuin Node.js?
No itseasiassa esim. https://github.com/civetweb/civetweb/blob/
flask
python -m http.server 8000
Missä mielessä nuo ovat helpompia?
Node.js on helppo, koska se on samalla kielellä kuin clientti.
JavaScript nyt vain sattuu olemaan ripulikieli
wy5vn kirjoitti:
JavaScript nyt vain sattuu olemaan ripulikieli
Ei, minusta erit. TS on parempi kuin Python ja on hyödyllistä, että serveri on samalla kielellä kuin client. Python:in laittaminen serveripuolelle lisää vain yhden kielen runtimen lisää, kun yhdellä tai kahdellakin pärjäisi. No, toki se on ihan hyödyllinen, jos projekti on erityisen pieni.
Mutta vaihtoehtoni yleiseksi serveriksi ovat oikeastaan web server C:llä tai web server JS:llä. Mielestäni Python ei tuota JS-serveriin mitään etua.
Java ei ole minusta helppo eikä tehokas. Se olisi, mikäli projekti olisi laaja ja C++ olisi liian kallis.
Mitähän erityisen hyödyllistä on siinä, että webbiserveri on kirjoitettu samalla ohjelmointikielellä kuin client? Serverin näkökulmasta tuskin on merkitystä mikä tai kuka http-pyynnön tekee.
jalski kirjoitti:
Mitähän erityisen hyödyllistä on siinä, että webbiserveri on kirjoitettu samalla ohjelmointikielellä kuin client? Serverin näkökulmasta tuskin on merkitystä mikä tai kuka http-pyynnön tekee.
No ei olekaan, mutta:
"Consequently, Node.js represents a "JavaScript everywhere" paradigm,[6] unifying web-application development around a single programming language, as opposed to using different languages for the server- versus client-side programming."
https://en.wikipedia.org/wiki/Node.js#History
Tuossa on etuna esim., että on helppo olettaa, että kaikki koodia lukevat osaavat melkein lukea myös server-side -koodit, koska heidän on web-konteksteissa pakko osata JS:iä client-siden takia. Sama oletus ei päde muihin server-side -kieliin.
Olen tämän kannalla, koska toinen dynaaminen kieli ei tuota juuri mitään lisäarvoa.
Server-side:lle siis joko C, C++ tai JS. Java, mikäli käyttää muutenkin paljon sitä.
Python:in oleminen server-side:llä ei edes taida liittyä sinänsä web-teknologioihin, vaan siihen, että Python on helpompi liittää C-kieleen kuin JS. Tämä on kuitenkin etu lähinnä vain kirjaston kehittäjän näkökulmasta.
Python server-side:llä on tosin sitenkin edullinen, että sitten saa Python-kirjastot käyttöön ilman jotain foreign funcion interface -kikkailua tms. Native-puolella saattaa olla reilusti enemmän Python-kirjastoja kuin JS-kirjastoja, eikö?
Niin, ehkä Python ei ole ideaali web-kontekstiin, mutta toisaalta sillä saavuttaa yhteensopivuuden monien muiden natiiviohjelmien skriptien kanssa.
Tämä voisi olla kanssa:
Entä saako Python:in jo clientiin?
Saa.
Eri asia on onko järkeä.
wy5vn kirjoitti:
Saa.
Eri asia on onko järkeä.
Niin no, tavallaan kallistun nyt siihen, että myös Flask on hyvä vastaus tähän. Django on ehkä liikaa, jos ei ole joku mini-sivujen massatuottaja.
http.server varmaan insofar tarkoituksena on vain testata sivua tai kehittää sitä lokaalisti.
"Warning: http.server is not recommended for production. It only implements basic security checks."
Ohjelmointikielten työkaluihin kuuluvat nettiserverit eivät ole tarkoitettu julkiseen käyttöön. Esimerkiksi Node.js-sovelluksen "eteen" pitäisi laittaa Nginx tai jokin sellainen. Paikallisen kehitysympäristön pyörittämiseen ne sopivat.
Node.js kylläkin toimii palvelimena, mutta ei kovin tehokkaana.
En ymmärrä, mitä etua olisi laittaa Node:n eteen jotain, koska Node rajoittaa edelleen asiaa. Toki sillä voisi kai laskea kuormaa, mikäli Node:ssa jostain syystä suoritetaan paljon prosessointia.
https://stackoverflow.com/a/53797242
"Client A makes an HTTP request to the reverse proxy. The reverse proxy makes an HTTP request to Server B. Server B sends an HTTP response to the reverse proxy. The _reverse proxy sends that data_ as its HTTP response to client A."
Miksi? Miksi Server B ei lähetä suotaan client:ille?
Vai ehkä muuskanuikku tarkoittaa, että Node.js on app server?
Pohdin tänään juuri, että mikä työkalu mahdollistaisi kevyen REST-rajapinnan JA nopean siirron nopeammasta backend-kielestä, kuten C++. Vaihtoehto olisi tietysti, että kaikki on C/C++.
Tämä konsepti on kai https://en.wikipedia.org/wiki/Reverse_proxy, mutta tuossahan on juuri tuo ongelma, että miten Node:n kapasiteetti muka olisi parempi Nginx:n kanssa, koska se edelleen rajoittaa väylää. Miksi ei laita pelkkää Nginx:iä?
Toki tuossa voi olla sitten varmaan mikä tahansa kevyt framework, kuten Flask.
Olettaisin kuitenkin, että ollakseen tehokas, reverse proxy:n ja web server:in on pyörittävä eri koneilla tai vähintään eri threadeilla.
Onko tämä helppoa vs C/C++?
---
Jotain vastauksia:
Erit.
"The web application is a web server, and can accept HTTP requests directly. Examples of this model:
Almost all Node.js and Meteor JS web applications (https://lookback.io)."
mavavilj kirjoitti:
En ymmärrä, mitä etua olisi laittaa Node:n eteen jotain, koska Node rajoittaa edelleen asiaa. Toki sillä voisi kai laskea kuormaa, mikäli Node:ssa jostain syystä suoritetaan paljon prosessointia.
Nginxillä:
-SSL/TLS käsittely
-Kuormantasaus useamman node instanssin välillä
-virheen käsittely valmiina.
noin muutaman mainitakseni
maka78 kirjoitti:
(10.02.2025 10:52:41): ”– –” Nginxillä: -SSL/TLS käsittely ...
Mutta voisi kai Nginx:in tilalla käyttää Nodeakin. Reverse proxy tuo kai on. Nodet app servereinä.
App serverillä ei kuitenkaan tarvitse olla web serveriä sinänsä, joten Noden serveröintiä ei tarvita, vaan siellä voi myös olla pelkkä frontend-sovellus.
Mutta yllä sanottiin, että Node app on sellainen, jossa web application on web server.
mavavilj kirjoitti:
maka78 kirjoitti:
(10.02.2025 10:52:41): ”– –” Nginxillä: -SSL/TLS käsittely ...
Mutta voisi kai Nginx:in tilalla käyttää Nodeakin.
Voi toki ja saharassa voi lasketella. Nginx on muutakin kuin reverse proxy. Se on vain yksi ominaisuuksista.
SSL/TLS terminointi, skaalattavuus, helppo konfattavuus, rate limitter, DDos suojaus jne. on aika kivoja.
mavavilj kirjoitti:
Mutta voisi kai Nginx:in tilalla käyttää Nodeakin. Reverse proxy tuo kai on. Nodet app servereinä.
Mikä vaan voi olla app serveri, oli se sitten php softa, C/#/++/, Pythonilla, rustilla, Delphillä tai millä tahansa tehty. Joko itse koodattu tai kirjastoa hyödyntäen.
Nyt kuitenkin erona on siinä että esim apache2 ja nginx on tuotantokelpoisia valmiita sovelluksia, webpalvelimia, joissa on siihen suunnattuja ominaisuuksia vaikka ja kuinka.
Node on runtime, jolla ajetaan javascriptiä. kuten JRE Javalle tai CLR C#:lle jne. Eli kysymysasettelusi on aika outo, koska oikeasti kysyt onko jonkun ohjelmistokielen runtime parempi webpalvelin, kuin joku ihan oikea webpalvelin. Jo pelkästään nodellekin on useita webpalvelin-moduuleja, kuten nyt vaikka http-server (https://www.npmjs.com/package/http-server). Ne kuitenkin on tarkoitettu devaamiseen, ja tuotantokäytössä sitten siirrytään jonkin ihan oikean web-palvelimen käyttöön palveluiden edessä.
Esimerkiksi
Käyttäjä -> osoite.fi:443 -> Nginx reverse proxy ja HTTPS -> sisäinen osoite palvelu.svc.fi:3002 -> docker kontit -> Node Serve hostattu react appi portissa 3002
empä tiiä. nuo docker kontit nyt voi ainakin kipata mereen
groovyb kirjoitti:
Node on runtime, jolla ajetaan javascriptiä. kuten JRE Javalle tai CLR C#:lle jne. Eli kysymysasettelusi on aika outo, koska oikeasti kysyt onko jonkun ohjelmistokielen runtime parempi webpalvelin, kuin joku ihan oikea webpalvelin. Jo pelkästään nodellekin on useita webpalvelin-moduuleja, kuten nyt vaikka http-server (https://www.npmjs.com/package/http-server). Ne kuitenkin on tarkoitettu devaamiseen, ja tuotantokäytössä sitten siirrytään jonkin ihan oikean web-palvelimen käyttöön palveluiden edessä.
Selainkin on, joten miksei voi ajaa appia headless selaimella?
Vai olisiko Node.js:n perustavoite vain antaa skript kiddieiden kirjoittaa backendiin?
Luulin, että jotkin merkittävätkin palvelut pyörivät Node.js -palvelimella. Kuten:
Nämä jotkut kai yleensä siirtyivät PHP:stä. LinkedIn siirtyi Ruby:stä.
Sitten edut ovat tämmöisiä:
https://www.milesweb.in/blog/wp-content/uploads/2020/03/performance-compressor.png
https://www.milesweb.in/blog/technology-hub/node-js-vs-php/
maka78 kirjoitti:
SSL/TLS terminointi, skaalattavuus, helppo konfattavuus, rate limitter, DDos suojaus jne. on aika kivoja.
Tässä ketjussa taitaa olla kontekstina aloittajan suunnitelma mobiiliapplikaatiosta, johon sisältyy web-palvelin, nettiselain ja html-pohjainen käli. (Miksi? Kuulemma vähemmän rivejä ja parempi suorituskyky kuin React Native.)
Tällaisessa härpäkkeessä pyörivään palvelimeen kohdistunee melko erilaiset vaatimukset kuin yleensä.
jlaire kirjoitti:
(11.02.2025 12:22:43): ”– –” Tässä ketjussa taitaa olla kontekstina...
Eikä ole, vaan myös, että mikä on hyvä yleis-webpalvelin.
Luultavasti joidenkin mielestä Apache tai Nginx eivät ole erityisen soveliaita RAD-kehitykseen.
Muistetaan myös, että: https://wiki.c2.com/?PrematureOptimization
On tietysti myös yksinkertaista, jos web-serverin voi deployata lokaalina tai verkon yli riippuen siitä, että missä ohjelmaa ajetaan. Perinteisemmin tämä vaatii eri kirjastojen käyttöä.
Mutta toisaalta on tietyssä mielessä outoa, että pitäisi käyttää esim. WASM:a ja web-serveriä erikseen, vaikka ne saavuttavat suunnilleen samat asiat.
Lokaalin web-serverin tulisi olla kuin vain pelkkä natiivikielinen FFI, mutta etuna on, että itse sovellukseen ei tarvitse kirjoittaa useita eri API:ja eri suoritusympäristöihin, vaan voit esim. vain passata web serverille flag:in "local" tai "http" tai "websocket".
En muista varmaan, mutta luullakseni Nginx tms. lisäävät app:in kokoa aika paljon, jos ne pitää pakata binääriin mukaan, vaikka ne ajettaisiin lokaalisti.
Mutta esim. Android:illa C-kielinen web server Android NDK:ille tarjoaa paremman rajapinnan kuin Android SDK, koska sillä voi suorittaa koko Android-puolisen ohjelman C/C++:ssa ja tehdä appin selaimeen. Yhdistyy RAD selaimessa ja nopeus ja standardit C:ssä. Lisäksi ohjelmasta tulee hyvin porttautuva.
Ok, kiitos korjauksesta, nyt asia on harvinaisen selvä.
mavavilj kirjoitti:
Eikä ole, vaan myös, että mikä on hyvä yleis-webpalvelin.
Mitkä ovat mielestäsi toiminnalliset, ja ei-toiminnalliset vaatimukset hyvälle yleis-webpalvelimelle?
groovyb kirjoitti:
mavavilj kirjoitti:
Eikä ole, vaan myös, että mikä on hyvä yleis-webpalvelin.
Mitkä ovat mielestäsi toiminnalliset, ja ei-toiminnalliset vaatimukset hyvälle yleis-webpalvelimelle?
-rapid application development (välttämätön nykyaikana)
-yleisimmät standardit ja API:t
-helppo porttaus tai optimointi C/C++:lle tai Rust:ille, jos koodi ei ole näillä
-skaalautuu asfastascee tai sitten helppo porttaus (kuten edellä)
Kaikki C/C++ -kirjastot epäonnistuvat kohdassa 1. Monet Python, JS yms. -kirjastot epäonnistuvat kohdissa 3 ja 4.
CivetWeb C:lle ei ole kovin työläs käyttää, mutta se vaatii pedanttisuutta koodatessa, joten se ei ole yhtä helppo kuin Python-pohjainen. RAD:issa ei yleensä haluaisi miettiä jotain tyyppejä tai "onko tämä array nyt varmasti oikein kasattu" tai "mikäköhän tämän parametrin pitikään olla" tms.
Luulen, että joku Lua-pohjainen olisi hyvä kompromissi. Ne eivät vaan ole kovin suosittuja, joten nicheä ovat.
http://keplerproject.github.io/orbit/
En tiedä, kuinka hyvin Node.js portautuu.
Lopulta kaikki kohdat täyttää kirjasto, joka on jokin C-kirjasto toteutettuna tai bindattuna korkeamman tason kieleen.
Onko https://en.wikipedia.org/wiki/FastCGI vastaus?
Vaatimukset ovat aika outoja webpalvelimelle, miksi webpalvelin pitäisi itsessään tarjota apeja? Nehän koodataan erikseen. Outoa ettet pidä esim SSL tunnelointia, reverse proxyä, round robinia / HA-ominaisuuksia, access managementia tai muuta kuitenkaan olennaisena osana webpalvelimen ominaisuuksia.
Oletko tietoinen, että on eri asia saada sovellus kuuntelemaan portissa x tietyillä ominaisuuksilla, kuin toteuttaa varsinainen webpalvelin?
groovyb kirjoitti:
(11.02.2025 15:01:59): Vaatimukset ovat aika outoja webpalvelimelle...
Koska sitten se palvelee myös runtime:n tai VM:n roolia, olematta kumpaakaan. Eikä tarvitse olettaa edes esim. WASM:in olemassaoloa. Riittää olettaa socketien olemassaolo.
Tosiaan esim. Web API:t ovat kauniita: https://developer.mozilla.org/en-US/docs/Web/API. Voi käyttää natiivisysteemin ominaisuuksia, mutta ei tarvitse välittää natiivisysteemistä. Käyttämällä 3rd party web serveriä ei tarvitse myöskään välittää selainkoodista, vaan voi käyttää pelkästään sen socketeja.
Lisäksi joillain alustoilla voi rakentaa C-ohjelmia, mutta ne eivät välttämättä takaa mitään API:ia C:stä sinänsä (esim. Android), joten tämän API:n tulisi olla liikuteltava. Tällöin saman API:n saa mihin tahansa, missä on mahdollista kääntää C-ohjelma.
Java:han on suosittu siksi, että sitten kaikkien Java koodi näyttää tietyin osin samalta, niin ei tartte arvailla, että no "mitähän tämä kaveri ajatteli sitten täällä". API deklaraatiot voivat olla toki customeja, mutta se, miten API juttelee serverin, kanssa ei tulisi olla.
groovyb kirjoitti:
Outoa ettet pidä esim SSL tunnelointia, reverse proxyä, round robinia / HA-ominaisuuksia, access managementia tai muuta kuitenkaan olennaisena osana webpalvelimen ominaisuuksia.
"Yleisimmät standardit"
---
Tämä on minun oma keksintö, mutta keksin kerran, että websocket:illa voi oikeastaan koodata mitä vaan, koska sillä voi ihan hyvin siirtää vaikka kokonaisen ohjelmakoodin. Tällöin voin esim. generoida selaimessa, mutta suorittaa palvelimella.
mavavilj kirjoitti:
Tämä on minun oma keksintö, mutta keksin kerran, että websocket:illa voi oikeastaan koodata mitä vaan, koska sillä voi ihan hyvin siirtää vaikka kokonaisen ohjelmakoodin. Tällöin voin esim. generoida selaimessa, mutta suorittaa palvelimella.
Luuletko, että tietoturvan kannalta on yleisesti ottaen hyvä idea palvelimen päässä suorittaa vapaasti asiakasohjelman koodia?
jalski kirjoitti:
(11.02.2025 15:53:47): ”– –” Luuletko, että tietoturvan kannalta on...
En, mutta tämä oli esimerkki websocket:ien agnostisuudesta.
En ymmärrä, miksi pitää rajoittua johonkin Node.js:ään, kun socketeilla voi käyttää kaikkea muutakin. Useimmat FFI:t, tulkit yms. ovat ihan hirveitä. Sitten kuitenkin hurrataan, kun voidaan tehdä:
Mitä etua websocket tuo oikeaan sockettin.
wy5vn kirjoitti:
Mitä etua websocket tuo oikeaan sockettin.
No, että selaimet toteuttavat sen. Lisäksi siinä voi siirtää muita datatyyppejä eikä vain tavuja (vs TCP).
https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/send#data
Selaimen sandbox ei todellakaan paljasta OS:n socketeja.
Mutta tuossa ei siis tarvitse välittää, että miten joku JS client-koodi, runtime tai joku backend ruksuttaa, koska ainoa millä on väliä on, että siirtyykö data niiden välillä riittävin väliajoin. Esimerkiksi Javan JNI on melko vaikeasti mitattava ja siihen pitää kirjoittaa glue codea. Itse komputaatiot voi jakaa monipuolisemmin, kun välissä on vain siirtoväylä eikä jotain API:a.
Natiivikoodia kutsutaan esim. lähettämällä tietty viesti.
Emt, ehkä tätä voi nimittää message passing interfaceksi?
Miksi tämä on eleganttia, no:
https://en.wikipedia.org/wiki/Smalltalk
"In Smalltalk, executing programs are built of opaque, atomic, so-called objects, which are instances of template code stored in classes. These objects intercommunicate by passing of messages"
"Smalltalk is a "pure" object-oriented programming language, meaning that, unlike C++ and Java, there are no primitive types. All values are represented as objects and computation on integers uses message sending just like any other object. In Smalltalk, types such as integers, Booleans and characters are also objects, in the sense that they are instances of corresponding classes, and operations on them are invoked by sending messages."
Mutta toisin kuin esim. Smalltalkin VM, niin websocketin streamin asioita ei tarvitse etsiskellä, koska ne voi esim. prosessoida sekventiaalisesti ja käsitellä ne suoraan host-kielessä ilman mitään VM:ja. Näin ollen, pl. itse socket, FFI layerin nopeus on yhtä nopeaa kuin lukea array tai string-syöte host-kielessä. Eikä tarvita mitään ihme välikielinotaatioita.
Websocket on rakennettu oikeiden sockettejen päälle niinkuin kaikki muutkin korkeamman abstraktiotason jutut (http,sql,ssh, jne)
wy5vn kirjoitti:
Websocket on rakennettu oikeiden sockettejen päälle niinkuin kaikki muutkin korkeamman abstraktiotason jutut (http,sql,ssh, jne)
No kyllä oikeatkin socket:it ovat hyödyllinen abstraktio. Ne ovat POSIX-kompliantteja toisin kuin monet FFI:t ja runtimet.
Node:n kontekstissa Node on sinällään hyödyllinen, koska se on pieni, joten mikropalvelun saa sillä. Se ei välttämättä ole paras yleis-serveriksi.
Mikropalvelut saisi binääreilläkin vaikka C:stä tehtynä, mutta onko sellainen hyvää ajankäyttöä?
Kysymyksen voisi laajentaa, että onko helpompaa web serveriä app + web server -kontekstiin?
---
Kuitenkin, huomioonottaen sen, että suosituimmat teknologiat ovat JS, Python, SQL yms., niin käytännön ohjelmistokehitys nykyaikana vaatii nopeita työkaluja ensin, sitten vasta tehokkaita.
---
Alussa mainittu CivetWeb on kuitenkin https://en.wikipedia.org/wiki/Mongoose_
https://mongoose.ws/case-studies/tfg/
"Mongoose remains agile
Alan and his team were able to build a HTML5 application which delivered real-time data through a WebSocket using Mongoose."
Onko tämä sitten parempi abstraktio kuin Node.js tms.?
Selain on joka tapauksessa muodostumassa ellei jo muodostunut erittäin keskeiseksi aihioksi. Se on yhtä hyödyllinen kuin JavaFX.
mavavilj kirjoitti:
No, että selaimet toteuttavat sen. Lisäksi siinä voi siirtää muita datatyyppejä eikä vain tavuja (vs TCP).
Tavujahan tiedonsiirrossa aina vaan liikkuu ja näitä voi sitten käsitellä haluamallaan tavalla.
jalski kirjoitti:
mavavilj kirjoitti:
No, että selaimet toteuttavat sen. Lisäksi siinä voi siirtää muita datatyyppejä eikä vain tavuja (vs TCP).
Tavujahan tiedonsiirrossa aina vaan liikkuu ja näitä voi sitten käsitellä haluamallaan tavalla.
Point being:
Websocketissa on hyvä käytettävyys suhteessa useimpien ohjelmien vaatimuksiin.
Koska websocketien eräs pääkäyttökohde on app servereiden kanssa, niin voitaisiin kysyä threadissa myös, että mikä on paras/helpoin yleinen app server framework? Tässä kontekstissa Node on "by design" melko hyvä, mutta entä muuten.
Koska yllä todettiin:
"The web application is a web server, and can accept HTTP requests directly. Examples of this model:
Almost all Node.js and Meteor JS web applications (https://lookback.io)."
---
Joku väitti jossain, että WASM:sta tulisi keskeinen "app runtime", mutta emt. Tällöin tietysti serverin pitäisi osata sitä.
Tuolla yhdessä käytettiin:
Käyttötarkoitus pitkälti ohjaa menetelmää: Vertailu
groovyb kirjoitti:
Käyttötarkoitus pitkälti ohjaa menetelmää: Vertailu
Paitsi, että ilmiselvästi serveristä toiseen vaihtaminen ei ole triviaalia päätellen siitä, kuinka paljon edelleen on Apachea.
mavavilj kirjoitti:
Paitsi, että ilmiselvästi serveristä toiseen vaihtaminen ei ole triviaalia päätellen siitä, kuinka paljon edelleen on Apachea.
Mielestäni se ei niinkään kerro siitä että vaihtaminen olisi suoranaisesti vaikeaa, vaan siitä että ehjää ei kannata korjata.
Eli jos mikään muu vaihtoehto ei ole käyttötarkoitukseen selkeästi parempi, niin miksi vaihtaa vaikka se olisi teknisesti triviaalia.
mavavilj kirjoitti:
Paitsi, että ilmiselvästi serveristä toiseen vaihtaminen ei ole triviaalia päätellen siitä, kuinka paljon edelleen on Apachea.
En ymmärrä tätä, toki samalla serverillä voit pyörittää sekä websocketeja että vaikka grpc:tä. Ja kun puhutaan reverse proxyn käytöstä, on enemmän kuin yleistä että sovelluskerros tarjoaa enemmän integraatio- ja liittymäpintoja kuin websocket. Esimerkiksi nyt vaikka että front ja backend keskustelee graphql:llä, ja graphql subscriptionit tarjoilee websocket-liittymän. Ja vastaavasti sama softa voi tarjota vaikka rest-liittymän ulkoisille integraatioille.
Tämä keskustelu mielestäni pyörii yhä kehää siinä, ettei eroteta sovelluskerrosta ja webpalvelimen kerrosta toisistaan, ja on joku hyvin outo perusolettamus, että sovellus itse toimisi ainoana webserverinä.
Ja mitä tarkoitat Apachella tässä yhteydessä? Tuota apache foundationia vai lisenssimallia? Ja miten se liittyy siihen mitä ja miten webpalvelimia käytät? Esim apachen omaa webpalvelinta voit ihan hyvin käyttää kaikkien yllälueteltujen eri menetelmien webpalvelimena.
groovyb kirjoitti:
(06.03.2025 09:14:09): ”– –” En ymmärrä tätä, toki samalla serverillä voit...
Ajatelin, että oma API tulee välttämättä sidottua web serverin tarjoamaan, jonka takia jonkun Apache web serveriin perustuvat ison kikkareen portaaminen on sinänsä jo kallis ja vaativa operaatio.
Tämä tietysti motivoi, että valitessa web serveriä kannattaisi suunnitella myös mitä tapahtuu jos siitä pitää luopua joskus. Edullista voisi esim. olla, että kaikki I/O data on standardimuodossa.
ei siinä mitään tarvitse portata, teet vaan apachen web serveriin reverse proxy säännön. Siinä ei montaa riviä tietoa ole per ohjaus.
groovyb kirjoitti:
ei siinä mitään tarvitse portata, teet vaan apachen web serveriin reverse proxy säännön. Siinä ei montaa riviä tietoa ole per ohjaus.
Mutta ei se silloin anna uudemman serverin etujakaan ko. datalle, koska kaikki query menee silti Apacheen, joka voi antaa tai ottaa dataa. Se on silloin koko ketjun pullonkaula.
Se, mitä voisi tehdä on, että data serverillä on eri API kuin web serverillä, joten web server (Apache) ei ole se, joka päättää, miten tieto otetaan tai annetaan, eli data ei ole couplattu serveriin.
Niin, koko pihvihän on siinä että esim SSL tunnelointi on asiakkaan laitteen ja apachen webserverin välillä, ja tieto siitä ohjataan sitten itse softaan. jos sulla nyt siis on vaikka api.ohjelma.fi ja ohjelma.fi domainit, ja sulla on tähtiserti tuohon ohjelma.fi domainiin.
silloin samat https://api.ohjelma.fi ja https://ohjelma.fi osoitteiden sertihallinta on apachessa, ja sieltä sitten ohjataan kahdelle eri softalle domainista riippuen, softien ei tarvitse tietää serteistä mitään.
Joo mutta käsittääkseni reverse proxy -konfiguraatiossa se taustan data server ei voi antaa ja ottaa dataa clientiltä suoraan, koska niiden pitää käydä proxy serverin kautta. Tällöin ketjun bandiwidth == proxyn bandwidth, vaikka taustapalvelin olisi nopeampi.
Niin ei tietenkään ota suoraan, siksi siinä nimenomaan on se reverse proxy. ja vastaavasti jos sinne softaanpäin tuupataan DDOS hyökkäys, se webpalvelin voi suojata ohjelmistoa ja estää yhteydet sinne vahingontekijältä.
-> mikäli data on couplattu serveriin, niin kaikki couplattu pitää portata uudelle palvelinohjelmistolle, mikäli ohjelmisto päivitetään. Muuten ei voi saada uuden ohjelmiston (ainakaan kaikkia) etuja, kuten suurempaa kaistaa.
->-> palvelinohjelmisto kannattaisi valita ja suunnitella siten, että päivityksen portauskustannus otetaan huomioon.
Luulen, että valtaosa noista Apache web servereistä on nimenomaan couplattuja, joten niiden päivittäminen on liian kallista tai vaivalloista.
mavavilj kirjoitti:
-> mikäli data on couplattu serveriin, niin kaikki couplattu pitää portata uudelle palvelinohjelmistolle, mikäli ohjelmisto päivitetään. Muuten ei voi saada uuden ohjelmiston (ainakaan kaikkia) etuja, kuten suurempaa kaistaa.
Miksi niin olisi tehty jossain? Totta kai jos asiat tekee päin persettä, niin elämä menee hankalammaksi. Se, että sinä et osaa, ei tarkoita sitä että muut eivät osaisi.
Jotenkin vaikuttaa siltä että kun et juurikaan tiedä asioista, niin teet hullunkurisia argumentteja, joilla perustelet virheellisiä oletuksiasi.
mavavilj kirjoitti:
Luulen, että valtaosa noista Apache web servereistä on nimenomaan couplattuja, joten niiden päivittäminen on liian kallista tai vaivalloista.
Minulla taas on valistunut arvaus että alle 1% niistä on, jossa tapauksessa asia on irrelevantti tekijä suosiossa.
Anna vaikka yksi esimerkki yleisestä tilanteesta, jossa "data on couplattu" Apache web palvelimeen niin, että Apachen vaihtaminen johonkin toiseen olisi hankalaa Apachen käytöstä johtuen. Itse en ole tällaisista kuullut.
https://www.twaino.com/wp-content/uploads/2022/05/2-Client-Serveur-Bae-de-donnees.jpg
(lähde: https://www.twaino.com/blog/creation-site-web/serveur-apache/)
Tämä on kolmas hakutulos DDG:lla kuvahaussa hakusanalla "apache web server api".
Luulen siis, että seuraamalla yleisesti jaossa olevia ohjeita Apachen setupiin niillä saa nimenomaan couplatun systeemin, ellei osaa ajatella vähän pidemmälle.
mavavilj kirjoitti:
Luulen siis, että seuraamalla yleisesti jaossa olevia ohjeita Apachen setupiin niillä saa nimenomaan couplatun systeemin, ellei osaa ajatella vähän pidemmälle.
Niin siis ja miksi noita kuvassa mainittuja JSP-filuja ei voisi triviaalisti siirtää jollekin muulle weppipalvelimelle?
Grez kirjoitti:
(06.03.2025 12:08:13): ”– –” Niin siis ja miksi noita kuvassa mainittuja JSP...
Koska jos ne on couplattu Apacheen eli esim. niitä käsitellään get/set -metodeissa yms.
Node API esim. ei ole hyvin portautuva:
https://github.com/mozilla/spidernode
https://www.reddit.com/r/node/comments/gqh2z/
mavavilj kirjoitti:
Luulen siis, että seuraamalla yleisesti jaossa olevia ohjeita Apachen setupiin niillä saa nimenomaan couplatun systeemin, ellei osaa ajatella vähän pidemmälle.
Olen täysin samaa mieltä, että jos ei ymmärrä mistään mitään ja seurailee vaan ohjeita sieltä täältä lukien ja ei yhtään mieti mitä tekee, niin varmasti saa sellaista paskaa aikaiseksi, joka on hankala saada toimimaan millään muulla systeemillä.
Edelleen väitän että yli 99% Apache-palvelinpohjaisesta verkkoliikenteestä pyörittää sellaista tavaraa, joka on helposti siirrettävissä muullekin, ja ne idioottiräpeltäjät vastaa sitten siitä alle 1%:sta mitä jää jäljelle.
Eli vaikka noi idioottiräpeltäjät ei olisi koskaan syntyneetkään, niin se ei näkyisi merkittävästä Apachen "markkinaosuudessa", eli vaikea vaihdettavuus ei nähdäkseni ole merkittävä tekijä sille että "on yhä niin paljon Apachea"
Edit: toisaalta olen kyllä nähnyt niin paljon kuraa ihan tuotantokäytössä, että tuo 1% saattaa olla vähän alakantiin. Mutta edes 10% osuuskaan ei vielä hirveän merkittävää eroa tekisi.
No Apache on aika vanha, joten en näe miksi kukaan käyttäisi sitä muusta syystä kuin siitä, että sille on olemassa hyvät ohjeet ja paljon softaa, joka tukee sitä suoraan.
Kyllähän tuollainen maksaa jo esim. sähkössäkin, kun tuo on paljon vähemmän tehokas kuin jokin Nginx, joten se kuluttaa sitten enemmän sähköä samaan asiaan.
Tosin täällä on sitaatti, jonka mukaan Apache on energiatehokkaampi pienille kuormille:
Nginx taas on energiatehokkaampi, jos käyttäjiä on enemmän lyhyillä aikaväleillä.
Nyt minusta tuntuu että alat päästä paremmin jyvälle siitä mistä se yhä jatkuva suosio jatkuu. Eli tottumuksen voima on varmasti yksi tekijä, hyvä vertaistuki toinen ja todella monessa tapauksessa Apache on "riittävän hyvä". Monta muutakin syytä varmasti löytyy, jotka on merkittävämpiä, kuin tuo alunperin väittämäsi syy.
Energiatehokkuus voi olla hyvä syy käyttää jotain muuta kuin Apachea, mutta yhtä laillahan se on hyvä syy olla käyttämättä Node.JS:ää. Eli jos kaikki katsoisi vain sitä niin juuri kukaan ei tietenkään käyttäisi Apachea eikä Node.JS:ää.
Ainakaan Nginx ei ole historiallisesti tukenut paikallisia .htaccess-tiedostoja, eli hakemistokohtaisten muutosten tekeminen palvelinsoftaan peruskäyttäjänä esim. web-hotellissa on vaikeampaa ellei mahdotonta. Tosin sellaisten käytön luokittelen siihen yllä mainittuun idioottiräpeltämiseen muutenkin.
Palvelinohjelmisto on hyvin epäseksikäs osa "web service -ketjua", joten sen vaihtamisesta ei saa mitään automaattista etua. Ei sitä lähdetä ilmaiseksi tekemään omaksi iloksi. Kovin moni asiakas taas tuskin maksaisi erikseen päästäkseen käyttämään Nginxiä tai jotain muuta.
Parempi olisi kuitenkin, jos saisi samalla Apachen suoraviivaisuuden ja Nginx:n tehot. Tämän takia tämä ketju on luotu.
Mainittu CivetWeb on hyvin dokumentoitu ja Mongoose on melkein samanlainen.
Vastaavasti joku NXWEB on nopea, mutta aika omillaan saa väkerrellä, kun dokumentaatio on lähinnä:
"Read articles on this site + see source code. hello.c is an example of user module. nxweb.h contains function and struct definitions."
Mongoose ei ole web serveri ensinkään, vaan odm-kirjasto mongodb:n käyttämiseen.
Se on jo mainittu yllä, joten et lukenut, mitä sanottiin.
Mutta toistaiseksi CivetWeb vaikuttaa tosiaan minusta hyvältä perus-serveriltä. NXWEB, jos sen kanssa pystyy elämään.
Benchmarkit:
https://github.com/yarosla/nxweb/blob/master/
Jossain määrin kai nginx on tehokkaampi, mutta toisaalta se tukee vähemmän alustoja. G-WAN tukee reilusti vähemmän alustoja. Luulen, että nginx ei tule laajentamaan alustatukea.
Kaikki web serverit eivät ole tajunneet, että jos verkkoyhteys vain on hyvä, niin myös Android/iOS ovat valideja palvelinalustoja. Erityisesti, koska ne ovat energiatehokkaita käyttöjärjestelmiä.
