hello everyone can you give me nice ok
so good morning
it's really great to be here today so
today I'm going to talk about the
classic champagne problem that's most of
the successful mobile apps in the world
going to face with somewhere in the half
lifetime it's been all of you and it
called scale why champagne problem you
ask just because we are not going to cry
about the idea that there is new
thousand users the download of
application and but sometimes we need to
think different we need to think about
how to change the way that we work in
our day-to-day because at the beginning
it was pretty easy and super fast we had
a small company great team all of us in
the same room will probably work on the
same repo and we able to manage our
day-to-day work that developed me the
development a new feature do not
interfere for other team but from day to
day you start to realize that's your
goal and things got much more
complicated as your company grows your
up goals you want more features more
developer join to the teams and it's
indeed become much more difficult to
build the react native application with
a simple project architecture the build
breaks more frequently it became
impossible to work on a single repo I
have to admit that it's much more
complicated with react native just
because the idea that we are working on
three different environments me on my
computer his visual code for the
JavaScript we have Android studio Xcode
now we have to deal with NPM that we all
all of us of course
like and as well as with graden and
greater than maven now we even need to
use cocoa powder because I react native
put it into the into the framework you
just start to feel that it's actually
affect your app performance your startup
time is increased dramatically screens
Lord
slower and it's much more difficult to
test the call just because everyone
brakes are as are other teams features
there is a huge mess so if all of these
seems familiar to you congratulations
it's a sign that's you're up just hit
scale so hello again I'm Mui I'm from
Tel Aviv I originally came from iOS
background but today I'm mostly but
react native I must be focused on
performance and architecture of two
weeks application and I am currently
leading the mobile group in the company
today in my talk I'm going to give you a
brief overview about the history about
the story about Wix application define
together with you the problem we had and
how we solve them and give you some
secret sauce for a big scale application
and at the end we're going to discuss
whether it work for us so I'm just waste
your time so stick with me so if you are
not familiar with weeks which is a
company to create a stunning website and
manage your business and with with week
mobile application you actually manage
your sites and a new business on the go
let's take an example if you have
restaurant you can go to the website
creating a few seconds on a website and
immediately start getting reservation on
the mobile phone reserve a table get
orders send invoices to the user another
example you have a yoga class you can
create a website or not and create
services and your members can book a
service from the mobile well we started
our mobile drawn with weeks back in 2015
to be honest we took chance with react
native a big time I mean it was super
promising around for four five years ago
and we decided to go for it
today we are Yuja we have more than 600
different screens we live two versions
every week actually four because it's to
iOS and to Android we are more than
nineteen mobile developers most of them
came from web background not native not
mobile and
they're spread about 20 different teams
I want to start with a brief overview or
a problem like my friend's child like to
say a problem well stated is the problem
health sold we need to dive in let's
talk about scale I try to define it in
two sentence let's see if it's work
scale is the ability to grow without
compromising on development velocity and
to increase the velocity without
compromising on the product quality we
understand the problem the problem is
that you want too much we want to eat
all the cake it's actually it's not
working together grow velocity quality
in other words we want to able to
increase our team's members and release
more features but all of this without
affecting time to production if you want
all of this to be fast it's double
trouble because it's going to be a
nightmare so let's take a look about
simple react native application create
from scratch and we need to understand
if it's possible to work with this kind
of architecture with a big scale so at
the bottom we have the native SDK
nothing to do with react native at the
top level we have JavaScript in New York
this is actually where most of our
record is is put we put all of our code
in there all the screen all the business
logic at the middle we have the react
native framework it's include all the
iOS Java and the infrastructure of
JavaScript code and if we decided
suddenly that we want to create or use
another library from our own let's say I
want to create a QR code scanner to my
application so I need to use another
library and we call it react native
library with native library its include
both again javascript native ios and
android and then we left with the
javascript libraries where every
Tenniel's kid can put his malicious code
and put it in our application you all
know this is the architecture of
everything
application of react native most of the
time this is the problem
all of these dependencies all of these
entities are in the same repo and it's
pretty hard to maintain this repo is
what hard developers all of us working
on the same repo and I can change the US
Code for another team can break his
feature and now a lot of JavaScript developers will say
that we can move the JavaScript logic
outside separate them into different
libraries and then they can be a
dependency of the main repository but
let me tell you something it's something
which we try and it's even worse why
worse because it's make you work on a
different environment from production
let's say I have my own example project
it has different dependencies from the
magnification the manipulation of weeks
for example I'd go to the store and what
about date of dependencies what about
dependencies that have in the main
application it's a hell for us it was a
chaos so I want to try to count the
issues with you we saw that we have a
slow development cycle we had to build
every time the whole native project just
even with change a small line of code in
their script we have owner dip own and
owner issues we are working on the same
repo we don't put ownership by files
just by product so there is no
well-defined ownership for each feature
we tried we Perl mono repo it's the same
because we when we try to split it into
mono repo or dedicated repos for each
project it didn't help it became much
more complicated because then we need to
integrate it between two libraries
that's they're isolated from each other
local production we call it dependencies
hell it's just what what I talked about
if I have project that is not the same
like the production environment they
opted to go to the store it's it's it's
doesn't work
test the code became a nightmare I test
the code today it works
suddenly I want to ship it to production
no code change there is no conchae my
repository suddenly stopped work
after few hours I'm sure all of you face
with it after few hours of investigation
you suddenly I realize that it was a
dependency of dependency to someone
change and release last night and broke
my application we can use NPM lock but
it's not working so we need to change
the architecture of the application oh
okay we are creative up with you kidding
it's it's impossible it's impossible to
take and one repository 100 JS developers and
to decide suddenly to upgrade react
native it for us it was the freeze of
three weeks that we didn't release any
application to the store and we had to
change it so how we do it how we take
application for 160 million users and
make the development velocity much
faster when I design an architecture it
should fit your organization structure
in weeks we divided into such entities
not not so different from other
companies we just call them companies
you can think about company is a small
isolated team that's work like a
start-up in two weeks we have the weeks
to explore the week's blog the week's
chat each one of them has its own
developer product manager and UI and
their work isolated from each other no
connection between them in addition we
have professional entities called Gil we
have several gear that the Fed yields
and of course the mobile Gil so the idea
behind the structure is to make sure
that we all able to move quickly and
compete the other companies to use small
companies to achieve the same goal one
mobile application so in terms of go I
tried to translate our issues to goals I
want to achieve an independent
development each one of the team want to
ship his new feature as soon as possible
to production but important to say with
the same infrastructure I want them to
be in the same application
weaks is the web oriented company like
most of the companies we need to take it
into account
I want web developers to start develop
to my app without open Xcode no need to
know why to run Gradle maven scripts
just going through the repo and write
JavaScript independent deployment as
much as possible as much as possible to
production same as web it's not that
common in mobile but I want to use
feature and send it to production we
want fast more fast than before
we want the same their production
environment and we want to try to create
something like or as an application like
Chrome extension to Chrome and like
application to us we want to do the same
just four weeks mobile application so
back to our simple application it's not
really possible to achieve all the
dreams it's like you can think about all
the iOS application in the world work on
the same repo or on the same project and
ship together to the store it's
impossible so the key for success is
called separation of concerns the
president can bet on of concerns in the
backend the server guys call it micro
services in front-end they have
something that's called micro front-end
the separation can be in different ways
it can be vertically by feature it can
be horizontally by elders server or
javascript in iOS and Android each one
of them can be in different teams but we
decided to mix and match between all of
this variation so let's start to change
our entities and make sure that it work
first I want to split the higher level
the higher level JavaScript in react all
the JavaScript code well actually most
of the code is written in JavaScript
it's not making sense to put all of them
in the same in this single project so
the first plate is by infrastructure and
12 business logic they are probably
developed by different teams
there is deem to create the infra and
all the ways making their product now
let's concentrate in the production size
inside the total
we split it into companies some
different teams that each one of them
has a different product each would want
to work independently so retrieve them
we created something that's called model
what is model we currently have in
application more than 35 models for not
wrong it's mean that is around 20 30
teams that each team has its own model
models model is written model is
actually a mini week's application
inside up you can think about as the
application in iOS or an Android model
written only with JavaScript which means
the team doesn't need to hire any native
development any natively developers it's
used advantage for us models can of
course community with each other even
thought implemented different logic we
have tons of integration between them
between the teams each model should
actually include or implemented an
interface which is the contract with the
outside wall without with the other
teams so this was the model this was the
product side and now we're done with the
product teams let's focus on the left
side so we took all of these parts we
have the infra descript which include
the infrastructure of the app we are-
framework and all the native libraries
noted libraries if you remember should
be inside the ios and android project
and we put them into a new kind of
entity it's a new repo we call it the
engine so let's take a look much deeper
what is the engine the engine is
actually the the entry point of the
application when the app open the first
line of code is the app GS of the engine
it provide the infrastructure to all the
model what is infrastructure they they
can focus on writing the screens the
logic to talk with the product manager
we in the infrared
Pak Pak all the infra and put
into a single repo the engine of you saw
include all the native dependencies it's
important for the next bullet this is
actually the most important part of the
of the of my talk the engine include the
iOS and Android binaries this actually
make JavaScript code isolated from the
from the main project why if if we had
if you know what is the native code in
the native dependencies why can't we
build it in a head and then take the
JavaScript code and just inject it into
the product no need to build over over
again all the native project the engine
is the one that's load models with a
config file we will sort see it in in a
minute
it holds all the infra like push
notification handling error handling
network localization and accessibility
even fetching we swivel in the fetch and
we want to see if which model make a
fetch and how much take time it takes
and if there is any bottlenecks to
another the performance again you need
to think about an OS not about the
application but we create an an
infrastructure for other application to
come in so for me it really because the
structure of weeks is making is like a
different companies but you can think
about your company and actually each
company has different product teams and
each product teams want to do it
isolated from the others so it's used
advantage and the engine it's much
important most of the company is like
this but not not the same but the
infrastructure development single
infrastructure team this team included
native developer strong ones and if
necessary have native development in the
teams they can be the web so back to our
architecture what we left with we left
with the culturing with the JavaScript
libraries JavaScript libraries can be
common code between modules if you want
to share the same logic its JavaScript
you can do it it can be a common code
between
the mobile in the web because most of
teams has full stack developer the work
both on the mobile application and the
web so you can put all the logic
business logic in JavaScript libraries
and they use it both on the web and the
mobile and mobile stores if possible why
not
by the way we are big fans of open
source in weeks as a rule of thumb every
weeks non-related code should be open
source from the first commit me and
everything that is not business logic to
something which is weak C should be open
source because working with scale in
react native eight weeks we will like to
share our knowledge with the community
one good example is the UID react native
UI liebe
it's a mobile design library and you are
liable its make us to use consistent UI
in weeks and improve the velocity by far
from creating each one or used react
native components without the design and
we have weekly releases you can use it
at open source back to our game so
that's all that was the original
original structure of a small
application and we change it we created
a new entities 11 leveraging week's
organization structure we opened the
application to many teams you can see we
have models the engine and Josip
libraries it's on one hand give all the
developers freedom on one hand and you
different product UI an infrastructure
for all of them all of them have the
same functionality of push notification
all the developers and companies can 100
and can be 1000 they have the same
infrastructure for everything
localization no need to implement it by
Derron
now we have new entities how they play
together let's see where in in fact it's
it's super interesting our main app
repository that released to Google Play
and store it's just a config file
it's config file as you all know it's
called package JSON and it's have all
the list of dependencies
not the native one it has to kind of
dependencies one is the engine
the second is all the models it doesn't
contain any line of code so this
configuration file first of all the
engine and it passed all the list of
models to be loaded by the engine now
the engine know which model to load so
this is the first interaction between
engine and model the engine is taking
the list and turn them into new memory
and now we left with the job library
directive library can be dependency or
by the model or by the engine
it's depend if it's a moment low - it
can be dependency of the engine because
all of us use it but if a dependency
that for example can be shared code
between the chat team that used the same
code for web web and mobile it can be
dependency of the model so the biggest
change the we did is to take the pre
build native images that's most of the
application put it into the main repo
and move it into outside into a
different project this if it's all of it
seems familiar it's a concept that's
similar to export you someone is
familiar with Expo maybe you develop an
onside Expo week we want to create an
expo solution tailored specific for
weeks
you are developer not have to be native
developer but you can write your code
into application without open exon
without open Android studio it's it's
amazing and it means that all the model
developers have the same environment
they can take their own config we will
see in a minute put the engine only with
their own model I want to test my code
isolated from the others
it's same time that I build the project
the native project and ship it to NPM
package and then the model take it and
just run project to understand it better
let's see how model look like so model
include the source file the source
folder its include all
screen solid business logic and the
resources folder images and staff tests
if you want actually the modules run e
to e test with detox in our case and on
the same Nate project that run on
production so I just like duplication
put my code and test it and it has model
J's model J s is actually what I told
you the model need to implement an
interface the interface with the outside
wall with other models actually with
with the engine it has two kind of
functions one is declaration the
creation can be a prefix at the init
function which method I expose outside
services deep links because the engine
gets for example push notification I
want to know who with the models need to
take this purification Henry and help me
screen and the other side we have the
lifecycle events actually the image
should be there what happened in login
do you want to do something when the
user log in to the application maybe
when we log out who is the from the
application maybe you want to clear your
cache and all the rest is a lot of them
and we have the package.json the
package.json include dependencies only
javascript dependencies as we talked
about before and their dependencies the
engine it's why the engine just because
I don't have any example project I don't
have any iOS on android folder of useful
but I need to run the native application
somehow so we put it in del dependency
while in on dependency because the one
that bring the engine is the main
repository received in a minute and so
now it's mean that this package is on
wall the config file and load the engine
with all the native libraries the same
like in production and with my own model
if I have any in JavaScript libraries
perfect now what if I have an
integration with a different team so I
simply can add a new model from Adaro
outside my own team
and then I can use both of them so in
production we have 35 almost almost 40
models if I want to run my end to end or
test my code no need to take all of the
models and and break my code I just want
to test my isolated area and so how
development process of a mobile
developer he write his code he push it
to to get we use TF city building a
testing and testing only on his model
and then published version 2 n pm at the
second that is published at 20 M and tag
this in this model of GA we use GA like
it's ready to production his code can be
in production in seconds in minutes next
time I released the diversion
same like in the web so what about the
engine the engine is actually the main
point is included Android code the iOS
code this is the project's themselves it
have the source code the source code is
all the JavaScript call as I told you
it's all the infrastructure its
specification all the rest written in
JavaScript it's all before we go into
the package.json install the apk at the
app itself all the native application
again it's inside the engine and what
the packages and included packages
include all the native dependencies all
loaded for example because you want all
of the models use the same version we
released the engine every two three
weeks not like the model which can
publish a new version every day or twice
a day
and we saw it like like major version we
can break the models we it can be a
minor fix it can be implementation of
performance some something like react
native object because now it's much
easier if I want to upgrade my react
native application most of the job here
is to change the engine change the
native libraries or everything is break
and then I'm
new engine so the weeks are React developers
include just package.json its include
the engine and all the models if I have
a new models there is a new team in two
weeks
let's say blog or I have a new team
that's called achievement that want to
put his own meaningly mini application
in two weeks just add a new line
implemented the Model Ts put his screen
and it works out of the box now
communication between the models they
talk with each other okay but all of the
all of it is through the engine that
just before we want control about
although going into the inside
application so it's it's there is no
direct communication between two models
you don't require other modules and call
his function it's all by the API by the
model yes we have contact validation
it's much more scalable just because I
can listen to the interaction between
models I can understand if there is
someone then spam by broadcast all
application and the JavaScript thread is
is hired the normal way we analyze this
thing but both from dev and Boston
production we have bi what is the most
popular interaction between them super
important again it's like Android and
iOS do to our application they analyze
everything and we have follower of
communication you saw it in a
package.json at a clue we have
components each model exposed components
outside components can be screened or
just a component they expose methods
they expose events like a broadcast I
want to broadcast everyone something
let's say I have for example a model
with communication notification model is
the list of notification like Facebook
Twitter we have the same tweaks and if
someone click on notifications I want to
broadcast everything notification is
read so this kind should be a broadcast
and service is something different like
broadcast to everything to everyone
something and they want the result that
they have anyone wants something and
five of them will told me an answer so
it's different from broadcast then
Topsham so it's fallible of
communication so that's all we cover a
lot it's take time to understand all of
it but I promise you the limits work and
you can watch the video after world and
and with blog post them on Twitter and
you realize that it's much more it's not
much better than a small simple
application it's not necessarily
relevant to your app but sometime is
love life at the up lifetime you're
gonna change the change your mind how
you develop react native application so
this bring us to the end of the
presentation and for a big question does
it really work for us so yes it works
in terms of goal we achieve all of them
we got independent development each one
do it by separate from the other
we actually have much more web
developers than mobile developers and
they can use their own expertise to
create their features we want fast as I
say we can actually have the ability to
release version to production every day
twice day there is no problem with not
dependent on anyone and identical the
production environment just because they
adhere that we put the apk in the app in
outside project and the models take it
and open the same application like I
know it's when an app what else we have
easier reacting to application I talked
about it it's much easier to change the
coding in native clear API between the
teams much more scalable and we have
different belief process I'm not going
to elaborate it today because it's a
huge subject but actually if I have
native development shoot by the App
Store or the Play Store the Java Script
shouldn't be through this same channel
it can be by different channel models
can send directly they called into
production into the user front if just
like code push if you are familiar with
it's something similar we just send
javascript code directly to production
with that we achieved
totally web experience you do something
ship it to production test it you can
change it in a minute we have almost the
biggest react net project in the wall we
have there is Microsoft and Facebook and
we have tons of developers we have
developers in three different countries
20 groups and wine most of our code is
written in JavaScript just only 30% is
native almost all of the code 80% of its
shared between iOS and Android
we have mineral active users and it
works thank you
you
