Technologie pro real-time aplikaci

...

Dobře, děkuji.Použiju tedy NodeJS na backend a na frontend? A k těm Google Mapám - nebylo by lepší použít OpenLayers?Díky

vpixle: ale no tak, migrovat data do jiné databáze jen protože tam je klient, který si posílá málo dat? To je špatný přístup, mongo na to dostačuje. Btw, couchdb je v erlangu, couchbase je v c++ (stejně jako mongo, když už to sem taháš), ono se to plete :). Na tenhle přenos je nejlepší websocket nebo http/2, protože nemusí vytvářet spojení pro každý požadavek. Pouchdb komunikuje s couchem přes rest api, takže nevhodné. Krom toho udržovat kopii databáze se vším všudy na klientu není pro tohle nejlepší způsob, výkonově pro miliony údajů to je také katastrofa---------- Příspěvek doplněn 10.05.2016 v 21:34 ----------ano, defacto jo, node.js je framework pro javascript na backend, to jen pro upřesnění. Ale jo, je to z mého pohledu nejlepší cesta, s php bys příliš bojoval a jiný jazyk bych volil jen pokud bys na to už měl programátory, vhod přichází zejména python nebo java.OpenLayers použít můžeš, WebGL tam je poměrně dobře udělané a na tohle by šlo použít. Google naopak ti dává pomocnou ruku pokud jde o ty překrývající vrstvy a OpenLayers to musí řešit pro všechny mapy, takže to dělá sám a může to být o dost pomalejší. Ale vyzkoušej, nikdy jsem v tom tuhle aplikaci neprogramoval, tak nevím.

Ano, myslím že FlightRadar je skvělý příklad, ve své podstatě je tam stejný princip.---------- Příspěvek doplněn 11.05.2016 v 19:52 ----------Chci se ještě zeptat, nodejs použít tedy výhradně čistý, nebo by například Express framework neměl vadit?Děkuji

express klidně použíj, pak se mrkni třeba na sockjs pro websockety. Lodash pro práci s daty a kolekcemi.V Node.js není dobré používat obrovské frameworky typu nette, symfony, ale pouze malé knihovny, které dělají svoji práci. Php je samo o sobě dost neschopné, naopak node.js v základu umí spousty věcí. Javascript je naprosto netypový jazyk a vyplatí se psát co nejjednodušší a nejpřímočařejší kód, který se dá snadno ladit, než tvořit šílené MVC, to tam prostě nepatří.

Děkuji.Na backend použiju tedy NodeJs spolu s Express, frontEnd nechám čistý.Děkuji moc.

vpixle: ale no tak, migrovat data do jiné databáze jen protože tam je klient, který si posílá málo dat? To je špatný přístup, mongo na to dostačuje. Btw, couchdb je v erlangu, couchbase je v c++ (stejně jako mongo, když už to sem taháš), ono se to plete :). Na tenhle přenos je nejlepší websocket nebo http/2, protože nemusí vytvářet spojení pro každý požadavek. Pouchdb komunikuje s couchem přes rest api, takže nevhodné. Krom toho udržovat kopii databáze se vším všudy na klientu není pro tohle nejlepší způsob, výkonově pro miliony údajů to je také katastrofa

Nevim proc si tady tahas triko, samozrejme ze Couch zminuju nejen pro to, ze ma klienta. Netusim a ani nechci resit jestli uz nejaka datababaze existuje nebo ne. Pokud zacina na zelene louce (a jedine co ma je za dve odpoledne postavenej Meteor prototyp), je uplne jedno jakou databazi nakonec pouzije. Zatimco omezit podmnozinu dat, ktera se ma (v Couch-i) replikovat na klienta je snadne. Resit konsistenci, vypadky spojeny, mobilni pripojeni, praci offline, synchronizaci a samoleceni "az spojeni naskoci" je s Mongem peklo. Takze pokud se jedna o aplikaci, jejiz logika pobezi na jednom serveru a klient nikdy nebude offline je Mongo rychlejsi (ale v podstate jen nahrazuje PHP Nodem a mySQL nejakou dokumentovou databazi). Pokud maji byt klienti samostatni a rovnocenni (a minimalne cast logiky se bude dit na klientovi) a pokud ma aplikace (jednou) bezet na necem jinem nez na pevnou linkou pripojenem desktopu je Couch reseni, ktere je tolerantni k chybe v navrhu. Kdyz si "spatne vybere" Couch aplikace bude mozna predimenzovana, ale pobezi, kdyz si "spatne vybere" treba Mongo a za rok si nekdo vzpomene ze to cele musi byt mobilni a Fault-tolerant a ze je to kriticka podminka (protoze zadavatel meni nazor a zadani ;), nebude se stacit divit.