Atrasts internetā

[Wuu]

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.

[Mr.Key]

: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ē. 

[qwerty]

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?

[Wuu]

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.  

[briedis]

daGrevi, es vēl gaidu, kad pastāstīsi sīkāk par saviem fona procesiem, interesantos aspektus! :)

[daGrevis]

> 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?

[Blitz]

 

 

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; } ?

[daGrevis]

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

[briedis]

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...

[Wuu]

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

[daGrevis]

Man patīk kā Wuu tik īsā laikā no nooba izauga, viņaprāt, par profiņu. :)

[Wuu]

Es nerakstīju, ka es visu to daru, es jautāju vai kāds cits nedara.

Edited May 11, 2016 by Wuu

[F3llony]

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

 

Es nodarbojos. Un? Labi, robotus nevadu un CNC toč ne (lai gan labprāt uzfrēzētu sev šo to). Taču ar finansiālām tranzakcijām nodarbojos gan. Pie tam apjomos, kas varētu pilnībā mainīt Tavu definīciju par to, kas ir masīva datu apstrāde. :) Un FYI, 1k "ierakstu" sekundē rezultējas 2.5 miljardos 30 dienās. Pastāsti, kur Tu iegūsti 2.5 miljardus organisku datu punktu mēnesī ko apstrādāt? :P vai tie tev ir kaut kādi ģenerēti dati, pār kuriem tev ir pilnīga kontrole? :P 

[codez]

Man spēļu serverī katrs lietotājs 20 reizes sekundē sūta savas komandas un 20 reizes sekundē saņem stāvokļa izmaiņas, pie 200 lietotājiem sanāk ap 4000 komandu apstrāde un 4000 stāvokļu nosūtīšanas, pie tam katrs stāvoklis, ko sūta var būt 1 - 20+ lietotāju dati. Rezultātā apjoms var sasniegt pat 100k datu vienību sekudē. Pie šāda apjoma, trafiks parasti ir ap 10Mbs up un 1Mbs down.

Edited May 11, 2016 by codez

[Wuu]

codez, ir kaut kāda optimizācija, kam ko sūtīt, vai serverī visi lietotāji saņem visu informāciju? Tur piemēram karte sadalīt laukos, lai lietotājs saņemtu informāciju tikai par to, ko viņš fiziski var redzēt?