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ä.
Tähänkin vastaus, että se on kuitenkin Apache 2. Node.js ehkä joillekin proprietary software -faneille. Flask ehkä joillekin.
Valitsin Apache 2:n kuitenkin, koska se on sentään yleisin oikeasti käytetty. Ei paras, vaan yleisin, joten sitä kannattaa osata käyttää joka tapauksessa.
Esimerkiksi mainittu CivetWeb olisi muuten hyvä, mutta se on marginaalisempi, joten en ole varma, että tuoko sen tekniset edut lopulta vastaavaa etua. Nginx taas on lähtökohtaisesti kaupallinen palvelin minusta, ja monet artikkelit eivät pitäneet sitä aloittelijaystävällisenä vs Apache 2.
mavavilj kirjoitti:
Nginx taas on lähtökohtaisesti kaupallinen palvelin minusta
Voitko vähän avata tätä mielipidettä?
jlaire kirjoitti:
mavavilj kirjoitti:
Nginx taas on lähtökohtaisesti kaupallinen palvelin minusta
Voitko vähän avata tätä mielipidettä?
Eiköhän niiden taka-ajatus ole, että kaikista tulee lopulta Nginx Plus / tms. -maksajia?
Lisäksi nopealla vilkaisulla Apache:n saamat avustukset ovat ihan maapähkinöitä verrattuna F5:n talouksiin.
-> Pitäisi uskoa yhä vähemmän siihen, että F5 haluaa jakaa Nginx:iä ilmaiseksi.
Tosiaan jos käyttää Vue.js, niin siinä saa serverin pystyyn. Päivityksiä sivulle voi tehdä livenä. Palvelin on Node.js. Vue.js:n kanssa tässä ei tarvitse miettiä sen konfiguroimista tietylle frameworkille tms.
mavavilj kirjoitti:
Tosiaan jos käyttää Vue.js, niin siinä saa serverin pystyyn. Päivityksiä sivulle voi tehdä livenä. Palvelin on Node.js. Vue.js:n kanssa tässä ei tarvitse miettiä sen konfiguroimista tietylle frameworkille tms.
En näe miten VueJS liittyy servereihin? Aika monessa fronttiframeworkissä on toki SSR-mahdollisuus, mutta eihän se oikeastaan itsessään kerro mitään. Oleellista on "palvelimesta" puhuttaessa myös täsmentää mahdollisimman eksaktisti MIKÄ palvelin se on? SSR on hyödyllistä jossain tapauksissa jos tarjotaan webbisivuja ulos. Jos taas kyseessä on pelkkä REST API tai projektissa on useampi eri client jota joudutaan alustojen takia toteuttamaan eri tekniikoilla, nämä joutuu sitten erottamaan. Myös jos jokin intra toteutetaan SAAS-tyylisesti ja on enemmän dynaamista SPA-asiaa, voi olla että SSR:stä ei ole niin paljoa hyötyä kuin webbisivuissa. "Helppous" on suhteellista ja sidoksissa tavoitteeseen.
Sitten on olemassa vielä toki monen frameworkin devserverit (Vite jne... you name it), joita moni muukin kuin Vue käyttää. Näistäkin puhuttaessa olisin täsmällisempi mistä puhutaan.
Nyt kun luen tuon viestisi uudestaan ja yritän epätoivoisesti dekoodata mitä mahdat tarkoittaa, niin puhutko nyt siis juuri Vite:stä ja tämän dev-serveristä jossa on hot-reload ja HMR? Tämähän ei ole yksiselitteisesti sama kuin Node.js Kyllähän Viteä voidaan ajaa myös Denolla ja Buniinkin on suhteellisen pian tulossa ne Noden rajapinnat joita Vite tarvitsisi, eli pitäisi tulevaisuudessa onnistua silläkin.
tldr;
Vite !== Vue.js
Kysytään helpointa serveriä ja esimerkkinä on Node.js:
-> Helpoin on sellainen, jossa on lyhyt käyttöönotto ja joka luultavasti liittyy web-palveluihin selaimesta:
Lue vain asti: https://vueframework.com/guide/installation.html#vite
-> Serveri pystyssä, jonka toimintaa voi testata selaimessa. Eikä tarvinnut ihmetellä, että mikä Vite tai mikä Vue.js vielä.
Apache:ssakin tulee se perus-sivu selaimeen, mutta siihen pääsemiseksi vaaditaan hieman enemmän. Myöskin sen esimerkin muokkaaminen vaatii enemmän työtä. Osasin heti muokata Vue.js:ää, vaikka en ole koskaan käyttänyt sitä.
(Kyllä nää nyt kuulostaa Mosavirhe:en omilta ongelmilta, kun yllä kaikki muut tajusivat, mistä puhutaan. Alkaen viesteistä #2 ja #3.)
Seuraavaksi ajattelin kokeilla, että saako Vue.js:n Apache:n päälle, jolloin yhdistyy helppo API selaimessa ja yleinen backend. En lähtökohtaisesti näe, miksi haluaisin käyttää Apache:a ainakaan dev-serverinä.
---
Siis tarkennuksena. Kun kysytään helpointa, niin keskiarvokäyttäjää ei kiinnosta erikois-seikat, kuten mikä on mikäkin, vaan se, että asia on toimintavalmis haluttuun käyttöön nopeasti ja sitä on helppo muokata. Tiedätkö miksi Apple Mac on suosittu? Koska se antaa käyttäjille sen, mitä he useimmiten haluavat tehdä helposti ja nopeasti. Suurin osa sen käyttäjistä ei tiedä, että tietokoneessa on esim. komentorivi tai sen kernelin nimi on XNU.
mavavilj kirjoitti:
(11.05.2025 19:31:29): Kysytään helpointa serveriä ja esimerkkinä on...
Vau... et tajunnut yhtään mitä sanoin! :D Kuinka moni täällä tätä lankaa lukiessa tajusi aikaisemmista viesteistä, että sekoitat tässä fronttiframeworkin devserverin, kielen runtimen ja deployattavat serveristäkit keskenään? Koska mä en ainakaan tajunnut ja musta tuntuu, että et itsekään tajua miten keskenään sekaisin puhut noista! :D
Tottakai joku Viten deviservun käynnistäminen ja sen päällä frontin devaaminen on helppoa, koska se on tehty SITÄ VARTEN, mutta se ei ole myöskään tarkoitettu siihen, että sitä deployattaisiin mihinkään oikeisiin ympäristöihin! Siitä loppuu ammukset kesken heti, jos tehdään mitään mitä tarvitaan tuotantoon. Millä duunaat tietokannat ja niitä accessoivat leijerit Vitellä? Ja nimenomaan KESKIVERTOKÄYTTÄJIÄ kiinnostaa nämä seikat ja olet keskiverron alapuolella kun puhut noin! :D Mut kyl se siitä! Sit kun oikeasti joudut deployaamaan asioita tuotantoihin ja sun ohjelmat vielä tekeekin jotain oikeita asioita niin opit vielä!
EDIT: Ja öö.. Kyllä itseasiassa kiinnostaa jos keskivertokäyttäjinä puhutaan softa-alalla toimivista devaajista joiden on oikeasti erotettava asiat toisistaan punnitessa vaihtoehtoja ja tehdessään teknisiä päätöksiä. Ja mitäs paska-argumentointia tuokin on. Haloo.. eli nyt yhtäkkiä joku perusjamppa joka ei koodaa mitään on se johon verrataan, mutta koodarit ei tietäis komentorivisitä mitään? Epäilen! Todella surkeaa argumentointia! Täysin sivuraiteille! BUUU!!! YRITÄ EDES!!!
Mosavirhe kirjoitti:
Tottakai joku Viten deviservun käynnistäminen ja sen päällä frontin devaaminen on helppoa, koska se on tehty SITÄ VARTEN, mutta se ei ole myöskään tarkoitettu siihen, että sitä deployattaisiin mihinkään oikeisiin ympäristöihin!
No tässä taas on se, että kun kysytään helpointa ja esimerkkinä on Node.js, niin se sisältää ideoita käyttötarkoituksesta. Luullakseni dev-serverillä, kuten Node.js:issä, vietetään reilusti suurin osa ajasta, joten se on lähtökohtaisesti tärkein valintaan vaikuttava tekijä.
Toinen vastaus ketjun kysymykseen voisi olla LAMP, koska A ja P on usein jo käyttöjärjestelmässä mukana tai niiden asentaminen on hyvin suoraviivaista, kuten Debian:issa:
https://wiki.debian.org/Apache
https://www.php.net/manual/en/install.unix.
mavavilj kirjoitti:
(11.05.2025 19:51:32): ”– –” No tässä taas on se, että kun kysytään...
Et MISSÄÄN kohtaa aikaisemmassa vaiheessa lankaa maininnut, että puhut helpoimmasta deviserveristä ja yleistit tässä että KAIKISTA maailman servereistä tämä on nyt se helpoin. Ja toikin on itseasiassa väärin, että kaikki pitäisi laittaa sen varaan. Toki jos olet sitten devaaja joka leikkii vaan kehitysympäristössä eikä ota mitään vastuuta ja ei kiinnosta mitä tuotantoon menee ja miten valinnat vaikuttaa siellä, noin voi ajatella, mutta ei se ole todellisuus oikein kellekään alalla toimivalle.
Ja edelleen: Node.js ei ole dev-server...
Oletko kirjoittanut ainuttakaan serveriä joka tarjoaa REST API:n ja työntää webbisivuja ulos Node.js:llä ilman mitään frameworkiä. Ihan pelkällä Node.js:llä. Minä olen. Sinä selkeästikään ET ole, etkä tiedä (taaskaan) mistä puhut.
"Luullakseni dev-serverillä, kuten Node.js:issä,"
Näin ei voi sanoa. Ymmärrätkö?
"A dev server is typically an internal web server used for testing and running code in development. It is a web server." – jfriend00
(kaikki muut tajusivat, mistä on kyse)
Kertauksena: Kysymys ei kysy, mitä web servereitä on tai mihin tarkoituksiin, vaan mikä niistä on helpoin ja esimerkkinä on Node.js. Vastauksessa #2 tulee Flask ja #3:ssa on Python http.server. Eikä tarvinnut tietää mistään muusta mitään. Node.js:ssä on web server: https://www.w3schools.com/nodejs/nodejs_http.asp
Lisää aiheesta:
https://www.w3schools.com/nodejs/nodejs_intro.
Node:n oma Hello world web server -demo itse tekijältä eikä joltain random-internetkommentoijalta:
https://nodejs.org/en/about#about-nodejs (tekijät itse esittävät, että Node.js on web server ja vieläpä ihan "etusivulla". Miksiköhän tuolla ei ole Hello world:ina JavaScript-tulkki?)
(taas kaikki muut tajusivat, mistä on kyse)
mavavilj kirjoitti:
(11.05.2025 19:51:32): ”– –” No tässä taas on se, että kun kysytään...
LAMP on läjä valintoja joita ei voi verrata mitenkään Node.js:ään joka on itseasiassa vain yksi kirjaimista MERN/MEAN-stäkeissä, eli vain yksi osa sitä läjää useampaa teknologiaa jota noissa käytetään. Se, että tuot uuden avainsanan keskusteluun ei tarkenna tai korjaa nyt virheellisiä oletuksia tässä. Voit laittaa sata linkkiä jos haluat tai yrittää kierrellä, mutta se ei korjaa sitä, että teknisistä asioista tulisi puhua suhteellisen eksaktisti.
"No tässä taas on se, että kun kysytään helpointa ja esimerkkinä on Node.js, niin se sisältää ideoita käyttötarkoituksesta.". Joita et millään tavalla kunnolla valaissut ja oletit, että jotenkin sen tietää mistä.. siitä että sanoit Node.js?
Ja joo. Samoin kun tein tietylle hankkijalle fullstackiä, niin meillä oli DEV, TEST ja PROD serverit AWS:llä, jotka kaikki oli sit ihan eri purkkejaan. Ja ne eivät olleet käyttötarkoituksiltaan mitenkään verrattavissa Viteen.
Tottakai kaikki serverit kaikissa ympäristöissä on servereitä. Mutta nyt puhutaan siitä, että mikä on jonkun tietyn stäkin toimintamalli ja tarkoitus. Jos et erota Viteä Node.js:stä tai Apachesta niin.. siis.. pystyykö joku selittämään täällä mavalle, että mikä tossa ajatuksessa mättää :D
mavavilj kirjoitti:
(kaikki muut tajusivat, mistä on kyse)
No. Katsotaan miten asia on kun jengi vastailee tähän jos vastailee. Minä tajusin tosiaan vasta tänään, että et tosiaan erota noita toisistaan ja siksi puhut kuten puhut ja elät kuplassasi. Ehkä sulle tekisi hyvää ymmärtää jollain tavoin miten huonosti kommunikoit. Tämä ei ole vain yksittäistapaus.
mavavilj kirjoitti:
(11.05.2025 20:04:57): https://stackoverflow...
Ja Node.js ei edelleenkään ole web server.. Se on ihan yhtä webserver kuin Python runtime.
mavavilj kirjoitti:
(Kyllä nää nyt kuulostaa Mosavirhe:en omilta ongelmilta, kun yllä kaikki muut tajusivat, mistä puhutaan. Alkaen viesteistä #2 ja #3.)
Kaipaan silloin tällöin helppoa http-serveriä syystä tai toisesta ja viestissä #3 on komento jota yleensä käytän. Ketjun otsikon ymmärsin niin, että se olisi siihen mahdollinen vastaus.
Melkein mitään muuta sinun jutuistasi tässä ketjussa minä en ymmärrä.
(Lisäys: Viestissäni 11.02.2025 yritin arvata, mitä olet tekemässä, ja sehän meni aivan pieleen.)
Oleelliset:
- Node.js EI ole serveri vaan runtime, jolle voi koodata sellaisen ja jolle on kehitetty kirjastoja (Express, Koa, etc.) joilla voi kasata serveriohjelmia erilaisiin tarkoituksiin.
- Dev-serveri voi tarkoittaa kahta eri asiaa:
1. Se voi olla remotessa ajettava dev-ympäristö jossa testataan ja kehitetään jotain ohjelmistohanketta joka vaatii palvelimen.
2. Se voi olla fronttiteknologialle tarkoitettu kevyt websivua localhostissa näyttävä työkalu, joka tarjoaa usein hot-reloadin ja koodin bundlaamisen (Vite, react-dev-server, Turbopack, Webpack, etc.).
Ja kiitos jlaire! Joo, mäkin ymmärsin ensin noin, kunnes tämä Vite-sekoilu ja Noden sekoittaminen joksikin ihan muuksi alkoi.
jlaire kirjoitti:
Kaipaan silloin tällöin helppoa http-serveriä syystä tai toisesta ja viestissä #3 on komento jota yleensä käytän. Ketjun otsikon ymmärsin niin, että se olisi siihen mahdollinen vastaus.
Nimenomaan. Tällainen on se mainittu keskiarvokäyttäjä, jota ei kiinnostaa mitkään detailit, vaan se, että homma alkaa toimimaan ja sitä voi muokata. Kysymys on samanlainen kuin "missä on lähin WC?". Ei aleta silloin miettimään, onko oikean merkkinen WC tms. Toinen vertauskohta voisi olla työnhaun hissipuhe.
Kysymys ei ole asioiden erottelusta tms., vaan niiden käsittelystä kontekstissa, joka on helppokäyttöinen.
mavavilj kirjoitti:
(11.05.2025 20:39:15): ”– –” Nimenomaan. Tällainen on se mainittu...
Ymmärrä toki, että kysymystäsi ei tässä arvostella. Lähinnä väittämiäsi ja niiden paikkansapitävyyttä, sekä miten esität että olet ymmärtänyt asiat.
Omille argumenteille saa tukea siiteeraamalla jotain.
(Mosavirhe laitettu ignoreen tässä kohdin)
Mosavirhe kirjoitti:
Minä tajusin tosiaan vasta tänään, että et tosiaan erota noita toisistaan ja siksi puhut kuten puhut ja elät kuplassasi.
Eri asioita vertailtiin toisiinsa mielenkiintoisilla tavoilla ja vuosi sitten: https://www.ohjelmointiputka.net/keskustelu/
Tuli yhtäkkiä mieleen tämä xkcd :) https://xkcd.com/451/
WebView-"rajapinta" on Android:illa luultavasti helpoin dev-server, koska Node:a sinne ei saa.
~Kuten: https://stackoverflow.com/questions/13507438/
Siis esim. kuten GeckoView:
https://firefox-source-docs.mozilla.org/mobile/android/geckoview/index.
https://firefox-source-docs.mozilla.org/mobile/android/geckoview/
---
No https://www.ohjelmointiputka.net/keskustelu/
Ne eivät ole eri asioita kontekstin tarpeista riippuen.
mavavilj kirjoitti:
Omille argumenteille saa tukea siiteeraamalla jotain.
No jaa. Itseasiassa automaattisesti ei saa. Lähinnä, että siteeraa jotain "sinne päin" saa vaikuttamaan todella ääliöltä. Et ole itse siteerannut mitään validia varmaan ainoassakaan keskustelussa jonka olen sinulta lukenut :D Lähinnä tuntuu, että nekin todistaa todella heikkoa luetunymmärtämistä.
mavavilj kirjoitti:
WebView on Android:illa luultavasti helpoin dev-server, koska Node:a sinne ei saa.
Olen vähän pihalla, tarkoitatko nyt webview komponenttia? Sehän vaan näyttää selaimen enginellä nettisivua siinä komponentissa, eikä hostaa mitään omaa webserveriä
groovyb kirjoitti:
mavavilj kirjoitti:
WebView on Android:illa luultavasti helpoin dev-server, koska Node:a sinne ei saa.
Olen vähän pihalla, tarkoitatko nyt webview komponenttia? Sehän vaan näyttää selaimen enginellä nettisivua siinä komponentissa, eikä hostaa mitään omaa webserveriä
Niin, koska Android:illa ei tarvitse sellaista web-sovellukselle, koska se ei ole palvelinkäyttöjärjestelmä. Tarvitaan vain jotain, mikä on natiivipuolella keskustelemassa selaimelle. Puhuin WebView-"rajapinnasta" eli se, mikä liittyy siihen.
Kysymys onkin haastavampi, jos Android pitäisi olla alustana myös dev-serverillä, koska silloin helpoin web server on se, mikä on jotain Java/Kotlin.
Miten mava sä yleensä otat ton, että sun langoissa on about 10-30 kommenttia jossa kaikki hajoaa sille, miten epäselvästi esität asiat ja miten monta kertaa puhut ihan tajuttoman ohi asioita tai olet ymmärtänyt konsepteja väärin? :D
Onko sun psyykkeessä joku alloplastinen suoja, joka estää sua näkemästä tossa mitään ja kerrotko itsellesi olevasi vain "väärinymmärretty nero"? :D Tää on paljon mielenkiintosempaa musta ku nää sun kysymykset!
mavavilj kirjoitti:
(11.05.2025 20:52:33): ”– –” Niin, koska Android:illa ei tarvitse sellaista...
No eihän se silloin ole mikään webserveri, vaan tapa avata nettiselain ohjelmassasi. webview on selain, ei web-serveri
Aiss... tästä sais niin hyvää statistiikkaa! :D
Koska sillee yleisesti mä olen ymmärtänyt, että toimiva psyyke toimii näin: Jos jollekin kerrotaan nyt vaikka arviolta 50 kertaa jollain alalla, että se ei tajua jotain asiaa oikein, niin pitäs olla joku itseään korjaava algoritmi siellä, joka kysyis esim. itseltään, että "onko mahdollista että noilla muilla on joku pointti tässä?". Ja okei. Jos näin tapahtuu kerran tai kaksi, niin sitten voi argumentoida itselleen asioiden olleen yksittäistapauksia ja väärinkäsityksiä. Eli on ihan järjellistä jättää asia omaan arvoonsa eikä pohtia koko ristiriitaa enempää. `
Mutta sit jos tätä tapahtuu useammin, niin eikös yksilön olisi hyvä miettiä, että miksi sitä tapahtuu niin usein ja onko sitä pointtia todellakin? Ja onko niin hirveää olla väärässä, vai onko oikeastaan haitaksi sotia sitä vastaan?
Jos mietitään järjellä, niin kumpi on pahempaa:
- Olla väärässä, mutta saada mahdollisuus korjata näkemyksiä ja kehittyä ja sisäistää asioita uudesta näkökulmasta, tai..
- Olla väärässä, mutta ei myöntää sitä. Väittää vastaan ja jatkaa 10v. samalla linjalla ja olla aivan yhtä pihalla ja kuulla samat korjaukset sen jälkeen? Ja pahimmillaan luoda samalla väärinymmärryksen panssareita mentaalisiin malleihinsa jotka sitten vaikuttaa siihen miten jatkossa ymmärtää tulevaa lisäinfoa?
Ja en siis väitä, että konseptuaalisella tasolla ITC-maailman termistö tai toiminta yleisesti olisi helppoa ymmärtää. Tää on varmaan jargoniltaan hirveimpiä aloja, mitä on. Mutta sitä suuremmalla syyllä täsmällisyys olis paljon tärkeämpää!
groovyb kirjoitti:
mavavilj kirjoitti:
(11.05.2025 20:52:33): ”– –” Niin, koska Android:illa ei tarvitse sellaista...
No eihän se silloin ole mikään webserveri, vaan tapa avata nettiselain ohjelmassasi. webview on selain, ei web-serveri
Se toteuttaa samaa, mitä dev-server muilla alustoilla, koska esim. GeckoView toteuttaa vastaavankaltaisen API:n kirjastona:
Tuo on myös käytännössä nopeampi saattaa toimintaan kuin vaikkapa CivetWeb:in rakentaminen NDK:lla.
mavavilj kirjoitti:
(11.05.2025 21:09:01): ”– –” Se toteuttaa samaa, mitä dev-server muilla...
Aivan.. Eli se, että avaa vaikka omalta koneelta selaimella tiedoston jota editoi on nopeampi ja parempi "dev-server" kuin se että olisi mikään palvelin käytössä ollenkaan! :D Ja sit jos haluat hot-reloadia vielä yksinkertaisemmin kuin Vite ni asenna vaikka linuxilla reload niminen terminaalisofta ja tadaa! ONKO HELPOMPAA! EI OLE! 0 config! AMAZING!
https://imgflip.com/i/9tlgov
https://imgflip.com/i/9tlgs0
Esitän linkkejä väitteeni perusteluksi koska niitä pyydettiin!
Tämä Vite:n yms. tuominen sotki tätä hieman, koska nyt niissä on pienempiä eroja kuin esim. Apache vs Node.js. Kuitenkin, riippuen käyttökontekstista erot ovat merkittäviä.
Esimerkiksi, jos käyttökohde on yleispalvelin tai vaikkapa API-rakentelu eikä vain HTML (/CSS/JS) server tms., niin ...?
Flask kelpaisi edelleen.
Mikä on best of the both worlds?
https://dev.to/atsu/web-development-with-vite-vue-and-flask-40ep ?
mavavilj kirjoitti:
(11.05.2025 22:30:32): Tämä Vite:n yms. tuominen sotki tätä hieman...
En tiedä olenko vielä ignoressa, mutta nämä rehellisesti ovat mielipiteeni ja niihin vaikuttavat seikat:
Eteen kannattaa valita fronttityökalu josta pitää ja joka palvelee tarkoitusta (TypeScript optional, mutta vähentää testattavaa kun osa bugeista jää jo tyypityksessä kiinni):
Taakse kielellä ei ole väliä, ellei ole itseisarvoista (makuasia). Koska
olen enemmän JS-päädyssä, tässä omia valintoja:
Brunolla kannattaa ampua pommeja REST API:iin jos ei jaksa tusata curlilla.
Jos bäkkärin haluaa tehdä Pythonilla Flask on ollut paras frameworkki omasta kokemuksesta. SQLAlchemy on hyvä ja hyvin tuettu Flaskissä ORM:in integroimiseen. Serialisointi Marshmallowilla. PyTest on jees testailuun.
Ja jos on eeeextra hardcore ja frontti ja bäkkäri on erikseen (tai frontteja kaksi? webbi ja mobiili), niin pnpm:llä on tosi kätsyä tehdä monorepo/workspace jossa molemmat koodit asuu kivasti ja helposti hallittavissa. Parhaimmillaan voi jopa löytää koodia jota voi käyttää eri osien välillä! Mutta tämä on sitten haastavaa alkuun, jos ei ole tottunut! Tekisin tämän ehkä sitten kun on serveri tai pari takana tai migraationa jäljestä jos ei ole tuttua.
Good luck, soldier!
mavavilj kirjoitti:
Onko GCC-"rajapinta" dev-serveri? Siinä on:
https://gcc.gnu.org/onlinedocs/gccint/Front-End.html
https://gcc.gnu.org/onlinedocs/gccint/Back-End.html
Mosavirhe kirjoitti:
Jos teet projektia oppimismielessä omalla ajalla, ei kannata olla liian fakkiintunut yhteen tekkiin. Jos esim. ORM:n osalta et ole varma kumpi on kivempi, tee kummatkin ja vertaa prosessia ja löytöjäsi
Oppimismielessä kannattaa toki tehdä myös ilman ORM:ää.
jlaire kirjoitti:
mavavilj kirjoitti:
Onko GCC-"rajapinta" dev-serveri? Siinä on:
https://gcc.gnu.org/onlinedocs/gccint/Front-End.html
https://gcc.gnu.org/onlinedocs/gccint/Back-End.html
Jossain rajatussa mielessä, mutta ei kovin pitkälle ja ei ilman selainta, koska toisin kuin GeckoView:issä, niin siinä ei ole web-serverille tyypillisiä ominaisuuksia, kuten:
https://mozilla.github.io/geckoview/javadoc/
Siten, jos web-serverisi _käyttökohde_ on HTTP-viestien prosessoiminen, niin GeckoView on ilmiselvästi dev-serveriksi sopiva ainakin prototyyppi-tasolla.
Itseasiassa, jos GeckoView:in saisi X86-64:lle, niin käyttäisin sitä, koska se on varsin elegantti ratkaisu. Pitäisiköhän se portata?
Ilmiselvästi pelkkä termien "front-end" tai "back-end" esiintyminen ei viittaa web-teknologioihin. Toisin kuin asia oli esitetty, niin vääristit sitä lainaamalla vain osan sitä, vaikka lainauksen yllä on annettu API-dokumentaatio.
jlaire kirjoitti:
Mosavirhe kirjoitti:
Jos teet projektia oppimismielessä omalla ajalla, ei kannata olla liian fakkiintunut yhteen tekkiin. Jos esim. ORM:n osalta et ole varma kumpi on kivempi, tee kummatkin ja vertaa prosessia ja löytöjäsi
Oppimismielessä kannattaa toki tehdä myös ilman ORM:ää.
Tämä! On oikeasti hyödyllistä tietää mitä loitsuja ne querybuilderit niissä muodostaa.
jlaire kirjoitti:
mavavilj kirjoitti:
Onko GCC-"rajapinta" dev-serveri? Siinä on:
https://gcc.gnu.org/onlinedocs/gccint/Front-End.html
https://gcc.gnu.org/onlinedocs/gccint/Back-End.html
Haha! Myöskin! Enpä ole tajunnut, että kun olen jakanut jossain C-projekteissa clientiin ja erilliseen backendiin jota käännetään dll:ksi jota client käyttää ja hotreloadaa, olen koodannut "dev-serveriä" 😂
Tuli mieleen tämä tästä:
https://en.wikipedia.org/wiki/
"The lines between the common interpretations of "file" and "file descriptor" are often blurred when analysing Unix, and nameability of files is the least important part of this principle; thus, it is sometimes described as "Everything is a file descriptor".[1][2][3]
This approach is interpreted differently with time, philosophy of each system, and the domain to which it's applied."
mavavilj kirjoitti:
(12.05.2025 11:56:19): Tuli mieleen tämä tästä: ...
Mielestäni serverin määritelmään kuuluu, että se on erillinen ohjelma jota ajetaan ja se tarjoaa resurssejaan joita jotkut muut käyttävät. Näkymätasolla ajettavaa asiaa en kutsuisi serveriksi ja en myöskään ducktypettäisi reaalimaailman konsepteja. Filejen monimuotoiseen käyttötarkoitukseen en vertaisi tässä kohtaa.
Omasta kommentista vielä: että kun puhuin dll:stä dev-serverinä, olin sarkastinen, niinkuin uskoin jlairenkin olevan gcc:stä.
Minusta siinä ei ole mitään hauskaa, ettei dll:ä voi pitää dev-serverinä, koska kuten file:jen tapauksessa, niin sen hyödyllisyys riippuu käyttökontekstista, kuten GeckoView:issä. Itseasiassa: https://learn.microsoft.com/en-us/windows/win32/com/dll-server-requirements. Mikäli tarkoitus on lähinnä vain vaihtaa jotain viestejä tai HTTP-viestejä, niin GeckoView on huomattavasti nopeampi ja helpompi kuin jonkin web server:in konfaaminen Android:illa. Siten, kun dev-serverin käyttötarkoitus on tällainen pienehkö, niin se on tällöin potentiaalisesti "helpoin dev-serveri".
Toinen esimerkki olisi se aiemmin mainittu API-rakentelu. On huomattavasti produktiivisempaa laittaa siihen esim. Node.js ja iteroida sillä sopivia rajapintoja kuin alkaa säätämään jonkin Apache:n tms. kanssa, vaikka tarkoitus on vain testata get/set-rajapintoja yms. Tällöinkin kyseessä on rajatussa mielessä dev-server:in funktiota toteuttava kapine.
"Everything is a file" esimerkillistää juuri sitä, että eri käyttötarkoituksissa eri työkalujen rajat blurraantuvat, jolloin myös "helppous" on monimutkaisempi asia. On totta, että GeckoView ei ole web server vaikkapa samassa mielessä kuin Flask, mutta se on, mikäli kontekstina on Android tai Android-yhteensopivuus. Lisäksi se voisi olla muillakin alustoilla produktiivisempi kuin Flask, riippuen käyttötarkoituksesta.
Tässä nyt nopeasti löytyi vaikkapa tämmöinen, missä testataan WebView:illä ja Messenger platform:illa bot-to-user interaktiota:
Joo no ei ehkä ole web server, mutta onko se helppo tuohon web:iin liittyvään ongelmaan?
Vai onko se/siinä serveri, kun tuolla on:
"STEP 9: Allow Messenger to _serve_ the webview"
Siinä on jopa SSR:
"A webview can help drive sign-ups with a custom form, render pages from an external CRM or e-commerce system, and more."
Tällöinkin, vaikka käyttötarkoitus olisi vain simuloida tuon kaltaista järjestelmää, niin Apache:n konfiguroiminen olisi ihan overkill:iä. Toisaalta sitä voisi testata esim. Node.js:llä siten, ettei testi ole sidottu tietyn toimittajan (Messenger/Facebook) API:iin. Myös Vite ja Vue.js olisivat overkill:iä, koska meillä voisi olla jo GUI. Jos me tarvitsisimme GUI:n testejä varten, niin olisiko Vue.js hyödyllisempi rajapinta kuin Node.js?
mavavilj kirjoitti:
(12.05.2025 12:30:18): Minusta siinä ei ole mitään hauskaa, ettei...
Tuossa sun jakamassa esimerkissä käytetään express.js:ää viestien lähettämiseen...
Eli josset nyt tästäkään tajua, niin se serveri tuossakaan ei ole webview tai messenger.. se on erillinen asia. Comprehende? No comprehende?
Kun näistä lainauksien käyttämisestä oli puhetta, niin tajuat varmaan, että jos vaan linkkaa jotain ja alkaa höpisemään ennen kuin on edes lukenut loppuun tai sisäistänyt lukemaansa ei vaikuta fiksummalta. Lähinnä tämmöinen tapa argumentoida toimii niille jotka eivät lähtökohtaisesti tiedä aiheista mitään tai ylikuormittuvat ja luovuttavat helposti. Mut jos asiaa aidosti tutkitaan perusteellisesti sitä ei kuulu lähestyä noin.
Ja edelleen puhut Vitestäkin Vuena vaikka on moneen kertaan ilmaistu, että nämä ovat aivan täysin kaksi eri asiaa. Mulla on melkein kaikissa fonttiprojekteissa Vite käytössä ja Vueen en ole koskenut yli 6:een vuoteen.
Minusta tämä kylläkin tarkoittaa, että se on Messenger platform:in idea serveristä:
https://developers.facebook.com/docs/messenger-platform/webhooks
Eli yläkäsite (https://fi.wiktionary.org/wiki/yläkäsite) on Messenger platform tai Facebook API. Käytännön ero on esimerkiksi, että luetaan Messenger platform:in dokumentaatiota eikä jonkin muun. Vue.js:n tapauksessa tilanne oli sama. Myös GeckoView:in tapauksessa tilanne on mielestäni sama. Luetaan sen dokumentaatiota eikä Node.js:iä, vaikka siinä olisi Node.js. Samplet:kin löytyy FB:n alla: https://github.com/fbsamples/original-coast-clothing/blob/main/app.js
_Kääntäen_ tämä voisi suosittaa, että express.js voisi myös olla yleinen web server.
Kuitenkin, jos tarkoituksemme on käyttää Messenger platform:ia, niin voi olla täysin tarpeetonta konsultoida sitä varten, että "mikä on express.js?" sen sijaan, että konsultoidaan, että "mikä on Messenger platform:in tapa toteuttaa serveröintiä tms.?". Abstraktioiden ideahan on, ettei tarvitse välittää kaikesta, vaan yleensä vain API:sta.
Eiköhän tämä viimeinen ole nimenomaan näin esimerkiksi pilvipalvelujen kontekstissa. Vai mietitäänkö jossain AWS:issä myös, että mikähän se oikea serveri on vai mikä on AWS:n idea siitä ja mitä AWS:n dokumentaatiot sanovat, että pitää tehdä?
---
Niin, koska minua ei ole vielä kiinnostanut niiden erot, vaan se, että mikä on helpoin ottaa käyttöön tiettyyn käyttökohteeseen. Kun asentaa Vue.js:n niin tulee molemmat. Tätä on helppous, muun muassa.
---
Tässä Messenger-esimerkissä Flask tms. ei ole ilmiselvästi helpoin, koska sitä ei ole integroitu Messenger:in dokumentaatioon. Tämä itseasiassa paljastaa juuri tuon, mitä juuri sanoin. Helppous riippuu kontekstista eikä muualla yleispätevä web server tarkoita välttämättä pätevyyttä tietyssä kontekstissa.
Kuten Node.js:n tapauksessa, niin on täysin validia sanoa, että Messenger platform sisältää web serverin tai vähintään ohjeistaa sen konfiguroimisen Messenger platform:in käyttöön:
https://en.wikipedia.org/wiki/Batteries_Included
Sen sijaan, jos meitä kiinnostaisi tutkia Messenger:iä suhteessa johonkin toiseen ohjelmaan, niin helppous voisi taas olla Node.js tai ehkä express.js. Helppous voisi kuitenkin olla myös esim. Flask, jos toinen ohjelmamme onkin Python-ohjelma(?)
Todellisemmin siirtyessä enemmän pois web-ominaisuuksista voisi olla hyödyllisempää joskus puhua Messaging API:sta. Ilmiselvästi ei Client API:sta, koska se vasta onkin laaja yläkäsite.
mavavilj kirjoitti:
(12.05.2025 12:58:56): Minusta tämä kylläkin tarkoittaa, että se on...
En tiedä oletko huomannut, mutta sulla taipumus venyttää käsitteitä siinä kohtaa kun olet puhunut itsesi pussiin. Nytkin tulkitset dokumentaatiota niin, että express ja node on jotenkin integroituna automaattisena Messenger-platformiin, ja sitten laitat loppuklausuuliksi että "vähintään ohjeistaa konfiguroimaan joten ON SAMA ASIA!" ihan vaa siltä varalta jos nyt olet ymmärtänyt jotain väärin, koska niinhän ei voi olla että olisit? Eihän?
Mä en, ja oletan ja saa korjata jos oon väärässä, että täällä kovin moni muukaan ei puhuisi noista käsitteistä noin ja tulkitsisi noiden seikkojen perusteella asiaa noin.
Messenger on client API. Clint APIt ovat agnostisia sille mikä datan lähettää, kunhan se noudattaa niiden APIn odottamaa formaattia. En näe tässä mitään "batteries included"-casea ja tässäkin tuntuu että käytät jopa tuota käsitettä virheellisesti.
Ei vaan Mosavirhe ei hyväksy sitä, että ihmiset tulkitsevat asioita omien kontekstiensa kautta (tämän olematta virhe, koska kyseessä on mielipide) eikä heidän YMMV ole välttämättä sama. Hänen ainoa tavoitteensa tuntuu olevan ampua muiden ideoita vääriksi ja esiintyä theone-jumaltietäjänä. Siksi hänestä on jo tehty ilmianto keskusteluhäiriköintinä:
https://www.ohjelmointiputka.net/keskustelu/
mavavilj kirjoitti:
(12.05.2025 13:25:39): Ei vaan Mosavirhe ei hyväksy sitä, että ihmiset...
Dude, ihmiset yrittää selittää sulle että tulkitset väärin, koska teet niin. Käsitteistön väärinymmärtäminen ei ole mielipideasia. Koska nytkin tulkitsen, että ajattelet jotenkin kummallisesti, että Flask ei voisi lähettää viestejä Messengerille ja toimia ihan hyvin. Olen ollut ehkä kovasanainen ja voin sitä pehmentää, mutta on ihmeellistä musta, että etsit näkemyksiä näin paljon muilta vastaanottamatta niistä juuri mitään. Sekin on kieltämättä häiritsevää. Mutta voin luovuttaa ja olla tästä lähtien kommentoimatta mihinkään. Se lienee järkevintä! Onnea koodausurallesi ja elämällesi!
Flask voisi, mutta tämä ei ole Messenger:in dokumentaation näkökulmasta uskottavasti helpompaa kuin se, mitä Messenger antaa. Siten se on luultavasti väärä vastaus Messenger:in/vast. kontekstiin.
---
Kirjoitetaan (tai tarkemmin lause ja kappale aloitetaan):
"Tässä Messenger-esimerkissä Flask tms. ei ole ilmiselvästi helpoin"
Sitten käyttäjä Mosavirhe tulkitsee, että tämä tarkoittaa, että "Flask ei voisi lähettää viestejä". Myöhemmin vielä todetaan:
"Helppous voisi kuitenkin olla myös esim. Flask, jos toinen ohjelmamme onkin Python-ohjelma(?)"
Takaisin ignoreen siis.
---
Dokumentaation vähättely on sitä paitsi amatöörimäistä, koska siihen käytetään runsaasti aikaa. Se on usein tärkeä työkalujen valintaan vaikuttava tekijä. Nopea lähde https://www.freecodecamp.org/news/understanding-modern-development-frameworks-guide-for-devs/:
"5. Long-term Maintenance
Community size and activity
Available talent pool
Corporate backing and stability
Documentation quality
Upgrade path complexity
"
Itseasiassa, jos helppouden kontekstiin otetaan näitä muita näkemyksiä, niin vaikkapa express.js voisi olla hyödyllinen sen takia, että Meta tms. tukee sitä.
Onko web server vähemmän vai enemmän (web) serveri kuin HTTP-serveri?
Joitain moninäkemyksellisiä esimerkkejä:
https://en.wikipedia.org/wiki/Web_server#/media/
Hyvä vastaus varmaan antaisi kirjaston, joka on helposti muokattavissa näihin kaikkiin, kuten esimerkiksi pelkkään View:iin MVC-ohjelmassa. Esimerkiksi groovyb:n kritisoima näkemys alla:
"Ei siinä sanota että node on serveri itsessään, eikä että serveri tarkoittaa edes web-serveriä. Tuossa yhteydessä serveri tarkoittaa sitä palvelinta jossa nyt ylipäätään bäkkäriä pyörität."
Ei kun, "server" on nimenomaan epäselvä käsite, koska se voi viitata eri asioihin.
---
Esimerkiksi Wikipedia:n artikkelissa on jo selvää, että web server on monimutkainen määriteltävä:
https://en.wikipedia.org/wiki/Web_server#Technical_overview
Tämän perusteella HTTP-prokolla vaikuttaa kuitenkin kiinteältä osalta, joten tässä kohtaa toteaisin, että olen osin hakenut hieman joustavampaa server:iä kuin vain web server, koska esimerkiksi jo mainitut WebSocket:it ovat hyödyllisempiä moneen tarkoitukseen, mutta en tiedä parempaakaan nimeä kyseisenlaiselle serverille, koska sellaisena käytettäisiin usein vaikkapa Node.js:ää, jota kuitenkin myydään selaimeen liittyvissä konteksteissa usein web server:inä, tai web server:iä käyttämättä HTTP-protokollaa.
En yhäkään usko että ymmärrät runtimen ja kirjaston eroavaisuutta. Node ei ole itsessään web-server, sillä voi toki tehdä sellaisen tai pyörittää sellaista, kuten millä tahansa runtimella. Vaikka pythonilla.
Summaten, Web-server tarkoittaa ohjelmistoa, joka jakaa ja vastaanottaa http ja wss protokollalla sisältöä tcp/ip verkkoon. Se ei ole sitä enempää tai vähempää.
Nodella voit tehdä sellaisen, tai käyttää valmista (kuten express tai serve). Joku on siis javascriptillä muita alikirjastoja hyödyntäen tehnyt web-server kirjaston jota voi node-ohjelmassa hyödyntää. Node ei siis tuossakaan tapauksessa ole se web-server, se ohjelmisto on jota noden runtimellä ajat.
Jos pelaat peliä windowsilla, pelaat peliä nimeltä X etkä sano että pelaat windowsia, vaikka se peli pyörii windowsin päällä.
groovyb kirjoitti:
(12.05.2025 14:42:51): En yhäkään usko että ymmärrät runtimen ja...
Ymmärrän, mutta se ei ole olennaista web server:eitä koskevan keskustelun suhteen, koska Node.js myydään esim. W3Schools:issa web server:inä, koska se on se olennainen anti siellä. Syytä W3Schools:ia ja Node.js:n omaa Hello world:ia. Lisäksi se, että siinä on web server antaa myös pääsyn JS runtimeen, mikä tarkoittaa sitä, että voi käyttää myös muita JS-kirjastoja. Web server -käyttäjälle tämä on kuitenkin sekundaarinen juttu.
Tulkitsen itse, että se miksi Node.js:n Hello world nimenomaan on HTTP-server on se, että se olisi itseasiassa Node.js:n yleisin käyttökohde. Jos olisi näin, niin olisi selvää, että Node.js on _käytännössä_ melkein synonyymi web server:ille monille käyttäjille. YMMV.
Lisäksi tämä on kaikki selitetty jo aiemmin, joten et lukenut, mitä sanottiin.
---
Alle:
https://www.w3schools.com/nodejs/nodejs_intro.
"Node.js is an open source server environment" (huom. ei sanottu, että runtime environment!)
"A common task for a web server can be to open a file on the server and return the content to the client."
"Here is how Node.js handles a file request:"
"What Can Node.js Do?
Node.js can generate dynamic page content
Node.js can create, open, read, write, delete, and close files on the server
Node.js can collect form data
Node.js can add, delete, modify data in your database
"
Tästä pääsee sulavasti tuohon äsken esitettyyn https://www.ohjelmointiputka.net/keskustelu/
---
Niin no, jos olet edelleen sitä mieltä, että on jotenkin ongelmallista nimittää Node.js:iä web server:inä kontekstissa, jossa se toteuttaa web server:in, niin sitten tämä on vaan YMMV. Minusta on ilmiselvää, että jos lukee W3Schools:ia, niin siellä esitetään "web server". Minusta oleellista on se, että se toteuttaa web server:in. Jos löydät muille kielille tai runtime:ille tms. vastaavanlaisen, niin se käy keskusteluun myös. Mutta kysymyksen kontekstissa halutaan käyttää vain web server:iä enkä runtime:ä tms., joka on selvästi laajempi kuin mikään palvelintyyppi. Tämä olisi kuitenkin selvää myös esim. Python:in http.server:in kanssa, joka oli vastauksena jo #3. Turhaa https://vainpelit.fi/mika-on-besserwisser/ Väärinkään olettaminen ei tuota mitään ongelmia web server:in käyttämisen suhteen, joka on alkuperäisen kysymyksen osa. Etenkään kun Node.js:n virallinen Hello world on web server: https://nodejs.org/en/about#about-nodejs
mavavilj kirjoitti:
(12.05.2025 14:45:32): ”– –” Ymmärrän, mutta se ei ole olennaista web...
Kirjaimellisesti w3schoolin node tutoriaalin ensimmäisessä kappaleessa sanotaan, että node mahdollistaa javascriptin ajamisen serverillä.
Ei siinä sanota että node on serveri itsessään, eikä että serveri tarkoittaa edes web-serveriä. Tuossa yhteydessä serveri tarkoittaa sitä palvelinta jossa nyt ylipäätään bäkkäriä pyörität
mavavilj kirjoitti:
https://www.w3schools.com/nodejs/nodejs_intro.
asp "Node.js is an open source server environment"
"A common task for a web server can be to open a file on the server and return the content to the client."
"Here is how Node.js handles a file request:"
"What Can Node.js Do?Node.js can generate dynamic page content
Node.js can create, open, read, write, delete, and close files on the server
Node.js can collect form data
Node.js can add, delete, modify data in your database
"Tästä pääsee sulavasti tuohon äsken esitettyyn, että mitä vaatimuksia web server:ille lopulta on.
Sinulla on melkoisesti nyt väärinolettamia. Tuossa kerrotaan että Node on avoimen lähdekoodin ohjelmisto, ja että yleinen web-serverin tehtävä on avata ja palauttaa tiedoston sisältö sitä kutsuvalle taholle. Tuon jälkeen on esitelty mitä tuohon tehtäväkokonaisuuteen liittyviä asioita voit noden avulla tehdä.
Ei se tarkoita että Node == Web-server. Tuossa voisi yhtä hyvin lukea Noden sijaan C++ tai vaikka Rust tai mikä tahansa, koska ne täyttää ihan saman luetellun ominaisuuksien kirjon.
ja Alussa kylläkin lukee että
What is Node.js? Node.js is an open source server environment Node.js is free Node.js runs on various platforms (Windows, Linux, Unix, Mac OS X, etc.) Node.js uses JavaScript on the server
lainaus:
Node.js uses JavaScript on the server
Noden oma virallinen määritelmä itsestään on seuraava:
lainaus:
Node.js is a cross-platform, open-source JavaScript runtime environment that can run on Windows, Linux, Unix, macOS, and more. Node.js runs on the V8 JavaScript engine, and executes JavaScript code outside a web browser.
