Jump to content
php.lv forumi

Atrasts internetā


briedis

Recommended Posts

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 by F3llony
Link to comment
Share on other sites

  • Replies 546
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...