All Posts in XPeppers

Dicembre 5, 2016 - Commenti disabilitati su Ruby Day 2016 – La nostra esperienza a Firenze

Ruby Day 2016 – La nostra esperienza a Firenze

by Alessio Coser, Christian Fei, Matteo Pierro

Sabato, 26 Novembre 2016, abbiamo partecipato al Ruby Day 2016 a Firenze (programma).

Presentazione del Ruby Day 2016

Presentazione del Ruby Day 2016

La conferenza è iniziata con l'intervento di Xavier Noria che ha proposto alcuni concetti di codice leggibile, corretto e conciso.

Abbiamo visto alcune porzioni di codice scritte in modi diversi: alcuni più concisi, altri più leggibili e ci ha fatto notare che la scelta di come scrivere il codice è molto soggettiva, ma che dovrebbe comunque essere condivisa interamente dal team in cui ci si trova.

Successivamente abbiamo deciso di seguire una presentazione improntata su Integration testing, di Piotr Szotkowski. Il ragionamento di Piotr è partito dalle problematiche emerse in questi anni su integration testing ed ha preso come esempio l'articolo di J.B. Rainsberger intitolato "Integrated Tests Are A Scam!".
E' partito con un'introduzione sui test doubles, come e quando vengono usati, ma soprattutto quali sono le loro limitazioni. Ci ha spiegato come Bogus (un tool per il testing) affronta questi problemi in modo diverso e ci aiuta nel tdd-outside-in.

Prima di pranzo Devon Estes ci spiega come applicare concetti funzionali ad applicazioni Ruby. Ci ha invitato a ripensare il modo in cui scriviamo il codice sfruttando concetti del paradigma funzionale mostrandoci alcuni esempi di come sia possibile scrivere codice testabile e mantenibile.

Ruby Refinements - Paolo Perrotta

Refinements the worst feature you ever loved - Paolo Perrotta - Ruby Day 2016

Nel pomeriggio Paolo Perrotta ci ha raccontato di una fantastica feature poco conosciuta utilizzata di Ruby chiamata "Refinements". Ci ha parlato di come questa feature sia un'arma a doppio taglio e del motivo per il quale è stata introdotta: cercare un'alternativa sostenibile al monkey patching.

In seguito Simone Carletti ci racconta come la sua curiosità verso altri linguaggi di programmazione (Elixir, GO, Crystal e Java in particolare) lo abbiano portato ad evolvere il modo con cui scrive codice in Ruby.

Il talk successivo, proposto da Benjamin Roth, era incentrato sul tema dei ServiceObject e su come comporli per creare quello che lui chiama realistic context. Ha sottolineato come un approccio del genere porti ad avere dei Controller più light e con meno codice ripetuto. A supporto della presentazione ha introdotto una serie di gemme che "facilitano" -l'applicazione di questa pratica. Tra queste quella che ci ha colpito di più è stata Waterfall.

Nel tardo pomeriggio abbiamo partecipato al talk Lessons learned while building Hanami di Luca Guidi.
Ha parlato di tutti gli aspetti che si celano dietro lo sviluppo e il mantenimento di un progetto Open Source, di come la comunicazione e la collaborazione siano aspetti molto importanti nella buona riuscita di progetti di questo tipo.

Secondo la sua esperienza la scrittura di codice arriva alla fine di tutte quelle azioni che permettono la crescita della comunità intorno al progetto come la comunicazione che deve essere “inclusiva“ e propositiva in modo da aiutare, chi lo desidera, a collaborare al progetto.

Inoltre ha toccato un aspetto molto importante: la gestione del tempo. Consiglia di dedicasi al progetto ogni giorno anche per poche ore. Però non proprio ogni giorno, infatti si dovrebbe riuscire a ritagliarsi del tempo (come il week-end) per la propria vita privata e non permettere che questa attività, anche se è appassionante, assorba tutto il tempo libero.

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Piotr Solnica ha concluso la giornata parlando della sua esperienza nello sviluppo di progetti OpenSource e di come la comunità cerca di migliorare l'ecosistema Ruby.

E' stata veramente una bella esperienza che ci ha permesso di confrontarci con la comunità Ruby e di passare una giornata divertente e stimolante.

Ottobre 25, 2016 - Commenti disabilitati su Reasons to adopt a microservices architecture

Reasons to adopt a microservices architecture

by Paolo D'incau

microservices

Microservices based architecture is a trending topic in these days: more and more companies try to take a big step and shape their software and internal organisation following the examples of well-established realities such as Spotify, Netflix and Zalando. Even though it's always positive to keep an eye on new technologies, languages and frameworks available in the market, it wouldn't be wise to blindly embrace them. In this article we will discuss with concrete examples three different reasons that should trigger your interest in knowing more about microservices.

1) Faster Deployment

One of the things that I have noticed in the past years of work on monolithic architectures is that most of the times the process of deploying working features in productions becomes difficult and time consuming. Let me try to expand this point and explain why I believe that a microservices approach can ease these kinds of organizational issues.

When the products you are working on becomes somehow stable and is actively used by customers, the daily work of your team splits in three different activities, that are:

  • new features implementation
  • bug fixing
  • changes of the existing features (small ones, most of the time)

If your code is organized in a monolithic structure chances are very high that your Continuous Integration/Delivery/Deployment pipeline will reflect the same structure which means that it has a unique flow and therefore each and every change to the codebase will need to pass through tests or build steps that are totally unrelated to the change itself; this obviously means that you need more time to deploy your new code in production with all the costs that this implies.

When you need to push to production an urgent fix, but your continuous delivery pipeline remains blocked by non related broken user acceptance tests for hours (they can even be tests on features that are seldom used) your team can undergo frustration and and irritability. I have noticed the same frustation to arise when someone (probably the PO) asks to deploy a given feature to production without deploying other features that are still not ready and the team just can't satisfy the request because the deploy follows the motto "get everything or nothing".

Microservices obviously can help in tackling these kind of issues. If you separate your big project in smaller services built around features you can obviously decouple the related code, with the great benefit that your deployment strategy will follow. This means that you can decide to create a different pipeline for each microservice and therefore you will be able to deploy each component indipendently decreasing drastically the time your bug/feature/change takes to be released and used in production.

2) Easier onboarding

So you develop and improve your software for quite a lot of time (can be years), but things change and some of your developers (I hope not all of them) decide to leave and seek their fortune away from your company. Your product is widely used in production and obviously it needs support and new features, so you decide to hire new developers.

For newcomers it can be really difficult to approach a monolithic codebase and to become productive in a few weeks. It is very reasonable if you reflect on it: your new developers have to understand not only the new business features that need to be added, but also the overall business domain and the way it was coded down by other people who left the project! A monolithic architecture is the main reason that made me hear during the last years things like: "To be productive on this codebase you need N months" or "A couple of years ago we decided that...", I bet you heard something like this during your career too!

If you hired new developers and you want them to be productive as soon as possible, you may consider switching to a microservices architecture. I strongly believe that with such approach new team members can develop all the new features you need in a faster way without the burden of a limited knowledge of what lies in the monolith. Also, I recommend that newcomers should practice work on these new features while pair programming with somebody with more experience on the project so that they can be thought about the business domain, monolith architecture and, why not, team/project history.

3) Smarter scaling

Scalability seems to be a big concern nowadays and it's very common to hear business people ask the dev team whether the system under development "will scale". With the advent of cloud and virtualization everything seems very easy: you just need to deploy your application to several machines and put some sort of load balancer in front of them (e.g. country based) and voilà: you get the scalability you desired almost for free.

While it's pretty obvious that today we have a lot of platforms and tool that comes to our help, it is worth to remember that the way we design and organize our architecture still plays a big role.

Suppose your application just became mainstream and day by day is used by more users: with a monolith, if you want to scale, you are forced to deploy everything to several "replica machines", without taking into consideration whether you need to scale all the features the application provides or just a small subset of them. This kind of approach introduces different business related issues in your organisation, not only technical ones: for example you will have to use several new machines that must provide the computational power needed by the entire application and obviously this will cost you more.

When talking about scalability, microservices seems to outperform many other architectural choices out there. Whenever you feel the urge to scale some part of the system (and I hope you are forced by real metrics and not by your gut) you can decide to spin new small machines that will host only the service that provides the needed feature and nothing more; so if you are running an online shop you will be able to scale only the part connected to searches, while keeping the parts that implement shipment tracking or products recommendation as they are.

With a microservices approach you will get another great benefit: you will be able to kill some of the instances with no mercy because you are confident that just by stopping one or more microservices you are not shutting down the entire system but only a part of it.

Conclusions

In this article we have looked at three good reasons that should address you towards a microservices based architecture when redesigning your legacy monolithic application or starting it from scratch. With microservices you can boost your team productivity, reduce your time to market and scale those parts of the systems that really need it.

It is worth noting that microservices are not the only way to achieve those results, so before embracing them you should evaluate different solutions and also consider the issues that this kind of architecture can bring into your organisation. Finally you should alway keep these words by Sam Newman in mind:

About me

I have a double identity: I code OOP by day and spread FP by night (and during the weekends). I love talking about Erlang, Continuous Delivery, refactoring and microservices. I fight for to the coding “made in Italy".
I've started collecting useful resources about microservices here.

Ottobre 13, 2016 - Commenti disabilitati su La crescita passa dalle persone

La crescita passa dalle persone

Ottobre procede alla grande con presentazioni, onboarding, percorsi di studio e moving motivators.
La qualità dei servizi che offriamo è frutto dalla qualità delle nostre persone e di una cultura fondata sul continuous learning, per questo siamo entusiasti delle ben quattro nuove persone nel grande team di XPeppers a Trento, Milano e Roma.

persone2

Gli abbiamo chiesto di raccontarsi in poche parole su di loro e sul loro ruolo in XPeppers

Giulio De Donato: Ciao sono Giulio De Donato, ho sempre orbitato nell'ecosistema opensource, ho co-fondato la community GoLang e Docker in italia, alcune librerie OS sul monitoring sono usate da Wikipedia e altre aziende, ho lavorato fuori dall'Italia per un piccolo periodo, ma sono tornato per portare un po' di passione, nel mio storico ci sono alcune aziende Italiane, il mio ruolo in XPeppers è quello di Tech Evangelist e Docker advocate, punto molto a metodologie di microservizi devops e buone pratiche.
Ho scelto XPeppers perchè mi da la possibilità di fondere lavoro e passione, mi aspetto che nel prossimo anno tutte le aziende Europee lascino il lato oscuro della forza per unirsi alle nostra unione fatta di buone pratiche e metodologie.

Giuseppe Cossu: Mi chiamo Giuseppe Cossu e mi sono avvicinato al Cloud Computing lavorando su OpenStack a partire dal 2013. Mi sono occupato dell'installazione e amministrazione di OpenStack con particolar interesse sul lato Networking (NaaS) partecipando ai progetti europei XIFI e FIWARE/FICORE. Nello stesso tempo ho coltivato l'interesse per l'architettura di applicazioni cloud-aware e per le recenti innovazioni sulla conteinerizzazione e la loro orchestrazione.
Il mio ruolo XPeppers e' DevOps & Cloud Engineer. La mia figura da un lato mira a creare, gestire e automatizzare il deployment di infrastrutture sul cloud, dall'altro a favorire l'integrazione tra le attività degli sviluppatori e dei sistemisti, assicurando un miglior processo per la messa in produzione del software.

Matteo Foccoli: Ciao, sono Matteo!
Ho cominciato da circa due settimane la mia nuova collaborazione con XPeppers. Dico nuova perché in realtà ho già avuto modo di lavorare, in maniera più o meno diretta, con voi: per alcuni sono infatti un ex collega e con la mia precedente società sono stato vostro fornitore.
Sono uno sviluppatore che negli anni è saltato da una tecnologia all'altra (da Java a Ruby passando per Javascript e altro...), conquistato fin dai primi anni 2000 dall'XP e dall'agile.
Ciò che mi piace di più della nostra professione è la possibilità di lavorare in team e condividere i risultati, motivo per cui negli anni ho voluto fare esperienza come Scrum Master e coach.
Per ora ho lavorato solo con i ragazzi qua a Milano, non vedo l'ora di conoscervi tutti! A presto!

Nicola Pedot: Ciao sono Nicola, sono uno sviluppatore affascinato dalla creatività ed eleganza di soluzioni pratiche che rendono l'informatica uno strumento in grado di eliminare le complicazioni in modo accessibile. Alla eterna ricerca di una definizione, sono in viaggio da programmazione procedurale, oggetti, funzionale ad agenti. Cerco di applicare in ogni cosa le tre regole dello spirito hacker-space: impara, insegna e condividi con quante più persone.

Vuoi far parte di questa squadra? consulta le nostre posizioni aperte

Settembre 29, 2016 - Commenti disabilitati su Come è andato il Lambda Zombie workshop

Come è andato il Lambda Zombie workshop

Un grande successo per il Lambda Zombie workshop, per la prima volta in Europa e primo evento lai organizzato con Cloud Alliance.

zombie workshop

Prima del workshop, Danilo Poccia, technical evangelist in AWS, ha spiegato il cambio di paradigma da una architettura monolitica ad una a microservizi, dal punto di vista delle infrastrutture e di come va a modificare l’organizzazione dei team.

IMG_0419
La seconda parte di apprendimento è stata sulle architetture serverless e il modo in cui consentono di creare ed eseguire applicazioni e servizi senza dover gestire infrastrutture. Danilo ha spiegato come rendere più facile la costruzione, gestione e scalabilità delle applicazioni sul cloud, eliminando gran parte delle problematiche derivanti dalla gestione dei server.

IMG_0425
L’evento sold out ha arruolato tantissimi volontari nella "AWS Lambda Signal Corps" per contrastare l’arrivo di ordate di zombie da tutto il mondo, monitorate tramite un Raspberry Pi collegato ad un SenseHAT.


 

Durante il workshop Danilo e Paolo Latella hanno mostrato i benefici di utilizzare Lambda per la costruzione di una applicazione di messaggistica e le integrazioni con servizi esterni.

zombie workshop

Lambda Zombie workshop

Salvato il mondo dall'invasione imminente abbiamo parlato del futuro davanti a una birra ?

IMG_0434
Visto il grande successo vorremmo replicare con nuove edizioni, anche in azienda. Dove vorresti vedere il prossimo evento? faccelo sapere

Settembre 29, 2016 - Commenti disabilitati su AWSome Day roadshow Milano

AWSome Day roadshow Milano

awsome day

Lo scorso 21 settembre abbiamo partecipato all’AWSome Day roadshow di Milano, una giornata di formazione gratuita rivolta a chi ha iniziato o vuole iniziare ad utilizzare il servizi cloud di Amazon.

Durante l'evento abbiamo presentato il nuovo calendario corsi per la formazione ufficiale AWS.


L’evento gratuito ha permesso ai tantissimi partecipanti di acquisire una comprensione più profonda di servizi di base e delle applicazioni AWS.


Il nostro Paolo Latella spiegato, con un certo savoir-faire, i concetti fondamentali di AWS dalle macchine virtuali allo storage, passando per database e networking.


Le prossime tappe sono Roma e Padova: https://aws.amazon.com/it/awsomedaysitalia-2016/
Ci vediamo li?

Settembre 16, 2016 - Commenti disabilitati su La nuova offerta di formazione AWS

La nuova offerta di formazione AWS

bundle up orizontal

Una domanda che ci viene rivolta spesso è come ottenere le conoscenze preliminari per seguire al meglio Architecting e System Operations on AWS, i nostri due corsi più richiesti. Queste informazioni sono contenute nel corso AWS Technical Essentials, una giornata di formazione per diventare competente nell'utilizzo della console AWS e non solo.

Per questo, in occasione dell'AWSome Day di Milano, e solo per 3 mesi, lanciamo una nuova offerta training:

  • Technical Essential + Architecting on AWS = € 1000 € 850
  • Technical Essential + System Operations on AWS = € 1000 € 850

Acquistando congiuntamente i due corsi, il corso Technical Essential è scontato del 60%, sarai in grado di approfondire le tue conoscenze sul cloud e prepararti alla certificazione AWS.

Contattaci per ottenere la promozione 

scade il 31/12/2016

Settembre 12, 2016 - Commenti disabilitati su Nasce XPeppers SAGL

Nasce XPeppers SAGL

lugano xpeppers

XPeppers continua a crescere, dopo molto lavoro dietro le quinte siamo felici di condividere questa notizia.

A Trento, Milano e Roma, oggi si aggiunge una nuova società per affacciarsi sull’Europa. Nasce a Lugano la partecipata XPeppers Sagl, con il desiderio di esportare oltre i confini italiani il nostro desiderio di agilità e cloud transformation.

Luglio 27, 2016 - Commenti disabilitati su Cloud Adoption in Corte dei conti

Cloud Adoption in Corte dei conti

Il cloud rappresenta un'opportunità di modernizzazione per la pubblica amministrazione e il case study pubblicato da Amazon Web Service per Conte dei conti ne è una dimostrazione.

corte dei conti cloud

Abbiamo collaborato insieme al reparto IT di Corte dei conti per costruire una soluzione tecnologica in grado di fornire una grande flessibilità nell'infrastruttura cloud di Corte dei conti.
Per fare questo abbiamo utilizzato i servizi di AWS come Amazon Elastic Compute Cloud e Amazon Lambda. Senza precludere la priorità della sicurezza, con il servizio di Identity and Access Management e la realizzazione di virtual private network connection, per ciascun dipartimento, verso i data centers di Corte dei conti.

Maggiori informazioni sul progetto direttamente nel case study di Amazon: ? https://aws.amazon.com/it/solutions/case-studies/corte-dei-conti/

Luglio 6, 2016 - Commenti disabilitati su Siamo diventati authorized AWS Channel Reseller

Siamo diventati authorized AWS Channel Reseller

Authorized AWS Channel Reseller

Questi ultimi tre anni di legame tra XPeppers e Amazon hanno lasciato intravedere il nostro futuro per l’area cloud. Questa partnership dimostra che ci sono moltissime opportunità per le aziende supportate da servizi e infrastrutture pronte a crescere con il loro business.

Il riconoscimento di AWS Channel Reseller Program ci darà la possibilità di offrire i servizi professionali e gestione delle distribuzioni AWS dei clienti finali del settore commerciale e pubblico.

Una componente importante di questo programma è AWS Support: una combinazione unica di strumenti e di competenze per aiutarti a realizzare cose straordinarie con AWS.
Nel suo ruolo di "chiave di volta" del piano Enterprise Support, XPeppers agisce come guida e consigliere, concentrandosi sulla consegna delle risorse migliori per il successo e il buon funzionamento della tua infrastruttura AWS nel tempo.

Contattaci per scoprire le opportunità per ridurre la spesa mensile e migliorare il livello di produttività.

Giugno 30, 2016 - Commenti disabilitati su Quando usare React Native? Una nostra analisi

Quando usare React Native? Una nostra analisi

react native

React Native è un framework per lo sviluppo di applicazioni su piattaforme native che permette di unificare l'esperienza di sviluppo su diversi sistemi operativi.

React Native è un progetto basato su ReactJS, che adotta un nuovo approccio allo sviluppo Web.

Attualmente è disponibile per lo sviluppo di applicazioni iOS e Android, ma a breve dovrebbe essere rilasciata la compatibilità con la piattaforma Windows.

Le peculiarità

I Componenti

ReactJS si basa sul concetto di componente. Il Componente è qualcosa che ha uno stato, che può accettare delle proprietà e che ha un suo ciclo di vita.

Questo approccio di sviluppo "atomico" risulta perfetto per effettuare Unit Test o per creare componenti più complessi includendone altri più semplici.

Approccio funzionale e Virtual-DOM di React

I React Components possono essere visti come funzioni pure e idempotenti, infatti l'interfaccia di un componente viene espressa chiamando il suo metodo render() che può accedere allo stato corrente ed alle proprietà.

Il flusso di aggiornamento di ogni componente avviene in questo modo:

  1. La gestione del Virtual DomSi esegue il metodo render() che riceve dei dati in input e restituisce un albero di contenuti da visualizzare (Virtual-DOM).
  2. Il metodo render() viene eseguito ad ogni modifica dei dati e genera un nuovo Virtual-DOM.
  3. React calcola le differenze tra il Virtual-DOM corrente e quello relativo allo stato precedente del componente ed applica le minime operazioni necessarie per avere il DOM reale aggiornato.

Questo approccio ha le caratteristiche della programmazione funzionale, infatti può essere visto come una funzione che prende in input 2 DOM e restituisce una lista di operazioni da eseguire sul DOM Reale per applicare in modo corretto i cambiamenti necessari.

Nessuna WebView

La WebView è uno strumento basato sul motore Webkit che permette di renderizzare correttamente pagine web formate da Javascript, Html e Css.

Molti framework ne fanno uso perchè permette di unificare lo sviluppo di una app che può quindi essere pubblicata sia su Apple Store che su Play Store, senza grandi modifiche.

L'aspetto negativo di questo strumento è che ha bisogno di molte risorse, quindi le applicazioni risultano meno performanti rispetto a quelle sviluppate con una UI nativa.

A differenza delle classiche WebApp, React Native mappa ogni suo componente attraverso l'interfaccia utente nativa della piattaforma iOS o Android.

L'approccio iniziale

Per un primo approccio a React Native può essere di aiuto avvalersi di un progetto ben configurato con un'impostazione modulare e Test Friendly per lo sviluppo.

PepporoniUn progetto interessante è Pepperoni: un modello open source che include una serie ditool già pronti all'uso.
Fornisce uno scaffolding sempre aggiornato di React Native, una struttura modulare ed è predisposto per effettuare Unit Testing con Mocha e Enzyme.

Mocha è uno strumento per il testing unitario di Javascript solitamente associato ad una potente libreria Chai.js, Enzyme invece è un tool che semplifica il testing dei componenti ReactJS.

Pepperoni, inoltre, integra delle librerie come Redux e ImmutableJS per la gestione dello stato dell'applicazione.

Supporta anche il caching dello stato applicativo che permette il funzionamento offline e l'apertura più rapida dell'applicazione.

Oltre ad un sistema di autenticazione (OAuth), ha molti altri strumenti che semplificano notevolmente la configurazione iniziale del progetto.

Pro

  • Di facile utilizzo
    Una volta capito l'approccio di React Native diventa molto semplice sviluppare nuovi componenti.
  • Più performante grazie all'interfaccia nativa
    React Native guadagna molto in termini di performance rispetto alle comuni WebApp, perché fa uso di un'interfaccia nativa e non delega alla WebView il rendering della UI.
  • Un ciclo di sviluppo molto rapido
    React native è a tutti gli effetti una applicazione nativa che interpreta la business logic scritta in javascript, questo permette di velocizzare notevolmente il ciclo di sviluppo: ad ogni modifica del codice non è necessario ricompilare l'intera applicazione.
  • Virtual Dom
    Questo approccio permette di calcolare il minor numero di operazioni da effettuare per apportare le modifiche al DOM guadagnando velocità nel rendering della UI.
  • Semplifica lo sviluppo di test unitari
    Grazie alla sua struttura a componenti atomici risulta più semplice e più rapido lo sviluppo di test unitari.

Contro

  •  E' comunque un'astrazione
    Nonostante la UI sia nativa, la business logic viene comunque interpretata, quindi risulta meno performante delle applicazioni native.
  • Permette minor controllo rispetto alle applicazioni native
    Nelle applicazioni native si ha un maggior controllo soprattutto sulla gestione delle performance.
  • Attualmente non supporta la piattaforma Windows
    A breve dovrebbe essere disponibile il supporto per Universal Windows Platform.

Alternative

  • Ionic
    ionicUn framework javascript molto comune che si basa su Cordova e AngularJS per la creazione di applicazioni mobile. A differenza di React Native, si avvale di una WebView che rende l'applicazione meno performante. Con Ionic, però, è possibile sviluppare una sola applicazione ed effettuare il deploy sia su Android che iOS (Develop once, deploy anywhere).
  • Xamarin
    xamarinUn framework C# per lo sviluppo di applicazioni native. Xamarin permette di scrivere una sola volta la logica di business modificando solo la UI in base al sistema operativo. E' già presente il supporto per Windows e, utilizzando XamarinForms, è possibile scrivere una singola UI per Android, iOS e Windows. Rispetto a React Native è uno strumento certamente più complesso ed è pensato per un team di sviluppatori già orientato allo sviluppo mobile.
  • nativescriptNative Script 2.0
    E' un framework TypeScript e AngularJS. Native Script permette di sviluppare applicazioni native senza utilizzare la WebView.

Conclusioni

React Native è sicuramente un ottimo framework che permette di sviluppare applicazioni con buone prestazioni ed una interfaccia paragonabile a quella delle app native. Questo strumento, però, ha indubbiamente alcuni svantaggi che si rispecchiano sia nelle prestazioni (anche se migliori di altri framework JS) sia nella possibilità di controllare tutte le funzionalità che una applicazione nativa può offrire.

React Native può essere una soluzione ideale per un team più orientato allo sviluppo in javascript. Questo perché offre degli strumenti che facilitano e, in qualche modo, unificano la logica di business e il deploy sulle varie piattaforme mobile.

Per uno sviluppatore di applicazioni native, invece, React Native può non essere il framework più adatto perché ha un approccio differente e potrebbe non rispondere a tutte le esigenze di uno sviluppatore mobile esperto.

Per sviluppare un MVP in poco tempo e con buone prestazioni rimane un'ottima soluzione, soprattutto se a sceglierlo è un team di sviluppatori Javascript.