F3llony Posted May 10, 2016 Report Share Posted May 10, 2016 (edited) Jo, jebkurš proces kurā ir iesaistīts cilvēks, būs grūtāk izdarāms, nekā ja mašīna runā ar mašīnu. Kā diez Tu nonāci pie tādas loģikas? :D Arī ņemot globāli un statistiki, Tavs arguments feilo, JO frontend = user interface. Obviously, javascriptā var uzrakstīt business stuff un nogrūzt to izpildei klienta pusē, bet vai tad tas būs frontend, vai uz klienta mašīnas izpildāms backend? Visa šitā semantika un kategorizācija ir milzīgs argumentatīvs fail. Jebkura procesa implementācijas kompleksitāte ir proporcionāla dotā procesa biznesa prasību kompleksitātei. Viss. Edited May 10, 2016 by F3llony Quote Link to comment Share on other sites More sharing options...
briedis Posted May 10, 2016 Author Report Share Posted May 10, 2016 > Nu pastāsti, tīri interesanti. Nu ko daudz stāstīt. Bija projekts kur daudzi mazi Dockerizēti servisi kas savā starpā runāja caur RabbitMQ asinhroni. Cik līmeņos viņi sarunājās, cik tādi procesi vienlaicīgi gaidīja (cik viņi bija saistīti)? Un kas tur bija sarežģītākais? Man tas tāpat izklausās diezgan sinhroni - viens process saņem vienus ievades datus, izdod ārā citus, pa ceļam varbūt izsauc citus procesus. Pa vidu varbūt nolocko kaut kādus resursus. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted May 10, 2016 Report Share Posted May 10, 2016 Frontends ir sarežģīts, kad jāuztur sarežģīts stāvoklis, jātaisa UI/UX tā, lai lietotājs tur nevar samudrīties, kā asinhroni izpildīt N lietas utt. Backends ir salīdzinoši vienkāršs tāpēc, ka tas sinhrons. Aplausi! Frontends ir patēriņa produkts. Taisot produktu, viss tiek piedots, vienkārši neizvēloties to produktu, bet izvēloties kaut ko citu. Frontendā prasās vairāk radošuma un enerģijas, jo patērētājs ir prasīgs. Vienā neveiksmīgā projektā uztaisīju tik labu frontendu, ka pasūtījumi un wow nāca paši no sevis. Diemžēl biznesa puse nebija pārdomāta un toreiz nebiju tik apņēmīgs, lai to ņemtu uz sevi. Bet nu frontends ir tā vieta, kurā, es domāju, "hard work always pays off". Quote Link to comment Share on other sites More sharing options...
F3llony Posted May 10, 2016 Report Share Posted May 10, 2016 Vienā neveiksmīgā projektā uztaisīju tik labu frontendu, ka pasūtījumi un wow nāca paši no sevis. Diemžēl biznesa puse nebija pārdomāta [...]. Bet nu frontends ir tā vieta, kurā, es domāju, "hard work always pays off". :D ... un kam tad gala beigās bija derīgs tas tavs uberais frontends? Blogā paspīdēt, cik kruts UI? Projekts jau tāpat nofeiloja... :D Quote Link to comment Share on other sites More sharing options...
Wuu Posted May 10, 2016 Report Share Posted May 10, 2016 Kā diez Tu nonāci pie tādas loģikas? :D Arī ņemot globāli un statistiki, Tavs arguments feilo, JO frontend = user interface. Obviously, javascriptā var uzrakstīt business stuff un nogrūzt to izpildei klienta pusē, bet vai tad tas būs frontend, vai uz klienta mašīnas izpildāms backend? Visa šitā semantika un kategorizācija ir milzīgs argumentatīvs fail. Jebkura procesa implementācijas kompleksitāte ir proporcionāla dotā procesa biznesa prasību kompleksitātei. Viss. Es tak uzrakstīju, ka es tā tikai domāju. Labs piemērs "iz dzīves", pamēģini ieviest produktu rūpnīcā kur 60% cilvēku domā, ja piespiedies nepareizo pogu, dators uzsprāgs. Tad pieredze tev pierādīs. Servera pusē, ja kas nestrādā, pats izlabo, kontakts pārsvarā 1v1. Servera kods 1+1 atbildēs ar 2, cilvēks 1+1 var atbildēt ar sazin ko. Un tad ej un izdomā, kā visu padarīt vienkāršu, lai pat kartupelis var to izdarīt. Nemaz nerunāsim par komerciāliem projektiem, kur tiek izsekota katra peles kustība un klikšķis. Lai tik lietotājs nospiež uz pareizās poga. Tā jau ir psiholoģija. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted May 10, 2016 Report Share Posted May 10, 2016 :D ... un kam tad gala beigās bija derīgs tas tavs uberais frontends? Blogā paspīdēt, cik kruts UI? Projekts jau tāpat nofeiloja... :D Nu tā tas arī ir. Netrāpīju. Nedomāju ar to paspīdēt. Varbūt pastāstot par to, atklāsies, ka ir jāmērķē pavisam citā virzienā, un ka iespējas vispār ir citur. Varbūt arī nē. Quote Link to comment Share on other sites More sharing options...
qwerty Posted May 11, 2016 Report Share Posted May 11, 2016 Wuu, kur tu īsti strādā? Ja runā par React, Sails, kaut kādām rūpnīcām. Man šķiet reiz kaut ko par noliktavām arī teici. Tas ir uzņēmums vai freelance? Quote Link to comment Share on other sites More sharing options...
Wuu Posted May 11, 2016 Report Share Posted May 11, 2016 Uzņēmums, sānu projekti, tagad ar freelancers un drīz arī pats pie saviem projektiem sākšu. Imho, šīs jaunās JavaScript tehnoloģijas, ļauj uzbliezt servisu pāris nedēļu laikā. Pēc papīriem esmu projektu vadītājs. Quote Link to comment Share on other sites More sharing options...
briedis Posted May 11, 2016 Author Report Share Posted May 11, 2016 daGrevi, es vēl gaidu, kad pastāstīsi sīkāk par saviem fona procesiem, interesantos aspektus! :) Quote Link to comment Share on other sites More sharing options...
daGrevis Posted May 11, 2016 Report Share Posted May 11, 2016 > daGrevi, es vēl gaidu, kad pastāstīsi sīkāk par saviem fona procesiem, interesantos aspektus! :) Bijām uztaisījuši tādu abstrakciju, ka ir bāzes klases ar nosaukumu `BaseService`, kuru manto visi servisi. Tad bija noteikta failu un direktoriju struktūra kurai vajadzēja sekot kad taisi servisu. Tālāk jau Docker mācēja no tā uzbūvēt image un pēc tam uzspawnot containeri. Katram servisam arī bija klienta klase. Ar servisu tu sazinies izmantojot klientu. Šeit ir pseudo-kods ar diviem servisiem: ~~~ class UserService(BaseService): def create_user(...): # ... def delete_user(...): # ... ~~~ ~~~ class PaymentService(BaseService): def deposit(...): # ... def withdrawal(...): # ... ~~~ Klientu klases nebija jāraksta — tās tika auto-uzģenerētas runtimā. Same ar worker kodu, tas arī nav service-specific. Nākotnē bija doma rakstīt klientus arī PHP, jo mums ir cita aplikācija, rakstīta PHP, kurai arī vajadzētu runāt ar servisiem. Tad ir, piemēram, web node kura, izmantojot klientu, runā ar servisiem kuri atrodas, iespējams, uz cita datora. Smukā lieta te ir tur, ka programmētājs, most of the time, var aizmirst, ka `UserService` atrodas uz cita datora. Tas kas notika under the hood, pateicoties RabbitMQ, bija taska ielikšana message queue. Tālāk jau `UserService` workers to paņēma uz izpildīja. ~~~ def sign_up(request): form = SignUpForm(request.data) if form.is_valid(): UserClient.create_user(form.data) # UserClient, nevis UserService. ~~~ By default visi taski pildās asinhroni. Metode `create_user` atgriezīsies instanti. Bija iespēja pateikt, ka gribi gaidīt rezultātu no vienas vai vairākiem calliem. Te jau parādās tas aync nature on backend, ko briedis noliedza. Redzi ka tomēr var būt. :) Arī patīkami ka šis viss scalojas horizonāli. > Cik līmeņos viņi sarunājās, cik tādi procesi vienlaicīgi gaidīja (cik viņi bija saistīti)? Procesi vispār nav saistīti. Viss kas viņiem ir kopīgs ir runāšana caur RabbitMQ. Ko tu biji domājis ar tiem līmeņiem? Quote Link to comment Share on other sites More sharing options...
Blitz Posted May 11, 2016 Report Share Posted May 11, 2016 Bija iespēja, pateikt, ka gribi gaidīt rezultātu no vienas vai vairākiem calliem. Kā tas tika realizēts? Messidžam pielikts klāt callbacks, un tad while(1) { checkMQforCallback; sleep; } ? Quote Link to comment Share on other sites More sharing options...
daGrevis Posted May 11, 2016 Report Share Posted May 11, 2016 Ja nekļūdos, pika (klients RabbitMQ uz Python) piedāvāja jau kko gatavu kas ļāva tā darīt. https://pika.readthedocs.io/en/0.10.0/index.html Quote Link to comment Share on other sites More sharing options...
briedis Posted May 11, 2016 Author Report Share Posted May 11, 2016 Nū, un kas te bija sarežģītākais? Mēs, piemēram, uploadojam failu pa taisno uz S3, tad frontends saņem callbacku, ka fails uploadots. Tad ieliek queue uz apstrādi. Tad kāds no backend serveriem paņem to failu, apstrādā, un nosūta eventu, ka ir done, Klients momentā saņem callbacku ar datiem par jau apstrādātu failu. Sarežģītākais tajā visā bija uztaisīt UI ar multi uploadiem, jēdzīgu callbacku apstrādi... Quote Link to comment Share on other sites More sharing options...
Wuu Posted May 11, 2016 Report Share Posted May 11, 2016 Kāds ar transakcijām, meklēšanu, masīvu datu apstrādi nenodarbojas? Vismaz 1k ierakstu sekunde, apstrādi? Kaut kādu robotu vadība vai CNC? Vismaz, kaut ko, kas nav saistīts tikai ar datu glabāšanu un nodošanu :D Quote Link to comment Share on other sites More sharing options...
daGrevis Posted May 11, 2016 Report Share Posted May 11, 2016 Man patīk kā Wuu tik īsā laikā no nooba izauga, viņaprāt, par profiņu. :) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.