React at scale with Vodafone

Good morning, afternoon, or evening, wherever you are in the world, and welcome. We're really excited to join the React summit this year and want to welcome you to our workshop about Vodafone and how they use the React technologies at scale. I thought I would take a minute to share with you some context about Vodafone for those of you who don't know this already.

Vodafone connects people around the world. We're present in 21 countries and 52 partner markets. You may not be used to seeing Vodafone and our brand at events like this but that's certainly something that's going to change and is changing. We have really big ambitions to transform our company into a tech comms provider. Our technology strategy sees us increasing our software engineering team by about 7,000 people by 2025. That means in 2025 we'll have a software engineering workforce of around 16,000 people. All building globally, and reusing across those 21 markets that we operate in. There is one technology team we're working on. We're on a journey to work collaboratively and avoid duplication so that we can be the most efficient team that we can be.

So a little bit about who I am and kind of why I'm launching the workshop. My name is Jamie Van Hankens. I'm leading a new team in Vodafone called Digital Ventures. Whilst the team name doesn't mean a huge amount, we're responsible for employee experience of our software engineers. We're working to implement changes that make it easier for our teams to work together. If you think dev advocacy, you'll be on the right track but our plans are to empower distributed developers to build products and services that are used by all of our customers around the world. Vodafone is really proud to be sponsoring the React summit this year and shortly you'll From our team in this workshop about how we use React technology.

You'll also be able to meet some of our team at the React event later this month in Amsterdam. So we're sending a fairly big group from our engineering teams around the world. Feel free to drop by if you're there to our stand. We'll have the stand there so you can talk to us. You'll be able to meet something called Spot the robot dog which is really cool if you get a chance to see it and much more so we hope to see you there. And then just the last bit in terms of introduction for me around today's workshop. So we're here to share our experience of using React at scale in Vodafone. So our team will introduce you to the My Vodafone app. That's our primary digital touchpoint for customers and we'll show its evolution in Vodafone. We'll also show you some key principles that we apply elsewhere in web to enable co-creation and reuse whilst ensuring kind of best in class UX and efficiency. We've saved some time through the workshop, so for Q and A. So feel free to use the Q and A functionality at any time in Zoom. We'll respond in chat and we'll pick a few questions to answer live with the group when we get to it. You'll be happy to know there's a coffee break about halfway through, so you'll get 10 minutes to refresh and then we'll kind of go into the second part. And then just lastly, if there's anything else that you'd like to know about Vodafone and our software engineering journey, we've got our QR code up on the screen that you can follow the link to and it'll just take you to one of our landing pages so that you can read more about it. I'm also on LinkedIn and so are a number of people on our team so if you'd like to reach out to us directly then, by all means, feel free to. But I think in terms of introduction, that's it. You've probably heard enough from me for now. So I'll hand over to Andrew to take you through the next step.

Andrew, over to you. Thanks Jamie OK, let me just get the control of the slides. OK, so my name is Andrew Ferguson. Just following on from what Jamie said, I actually work in what we call the group organisation. So, I've got a global role working across all the different markets that Jamie was talking about. And my team looks at two things. On one side, we've got a role around digital analytics and marketing. On the other the side is all about My Vodafone app. OK, which is what we're going to talk about today in the first section. And then, as we go through the web sections a bit lower down with Pedro and team, you'll probably start to see some synergies between app development and the web development. So, the React Native and the JS story that Pedro and team will cover later. One small apology. Unfortunately, due to personal reasons, the team from Albania couldn't join us today, but they were going to talk a little bit about how we're stepping from React Native development and just pure native development into a more, I suppose, progressive web app type environment. So, taking some of the code we're building on React Native, porting that to a web desktop type experience, and moving to a full progressive web app experience. So, we'll try and pick those things up later through the conference, and other sessions, and we'll try and touch on it as we go through. I'm just going to give you a quick introduction. So, Jamie set the scene around who Vodafone are, where we operate, and some of the drivers. I just wanted to pick up on some of those and talk about, specifically, what is the myVodafone application? Why are we so proud of it? And then step through how myVodafone application's changing from a technology perspective, and equally, how we're starting to use React Native to help us on that journey of transformation to a more efficient, shared, and non-repeated form of development. So in a source, et cetera.

Okay, so from a customer viewpoint, the myVodafone application, as Jamie said, it's our primary digital touchpoint. So, it is the most frequently used form of engagement we have with our customers, for customers to self-serve and interact with Vodafone. It's available in all of our 19 markets.

So, Jamie mentioned 21 markets. We have two joint ventures. So, the 19 wholly-owned Vodafone markets that we operate in, they all have a myVodafone application in the Play Store and Google Store. And those applications are there for the customers to interact. From historical perspectives, it's been mainly around, started kind of from care. So, the billing, the usage, and the self-care journeys. Customers wanting to interact, check their bill, pay their bill, and those types of things. But over the last few years, it's obviously grown far wider as the Vodafone service offerings have grown, fixed-line broadband, et cetera.

And, as we now grow into new, sort of, value-added services. So, in the 19 Vodafone markets we have, the app has grown into more of a converged proposition. And whilst we have a common design reference, so the look and feel, the interaction model, the branding, all the things you'd expect to look the same. If you download the Albania app and the Irish app, they kind of look the same. But actually, what you see within those apps is very different. So, they're very tailored to the local market needs. So, we have certain markets. Italy is a very prepaid market. So what they need to offer in terms of journeys within their app are very focused on, you know, top-up payment, checking your balance, viewing up-front. Okay? Whereas other markets, which are more into converged offerings, have a very different tailored journey set. Equally, in a market like Turkey, they're now kind of becoming the Amazon of Turkey and offering a marketplace where you can buy anything from groceries through to physical goods. Okay? So we have 19 markets. A common reference design that kind of goes across all of those to keep the branding consistent. But we have to recognize that every market has a very different customer set. And so the offerings, features, and journeys that you get in those markets are very much different. Okay?

In terms of the features, they're very much evolving. So as said, where we used to be very much on the what's my bill? What's my usage? How do I pay? Type journeys. Now we're getting into a lot more personalization. Trying to kind of get the customers to come back to the app more frequently. We have evolving needs around going from physical SIEM to eSIEM to self-provisioning. We want to do the full purchase and acquisition journeys and onboarding journeys with new customers. And we're also looking at other value-added services. So things like insurance, content, the marketplace, loyalty and rewards. So the feature set is very much growing beyond just care and usage. Okay? So it's a primary touch point and it's ever growing and it's different in every market.

From a technology perspective... Oh Jamie, you might have to help me with the page down, alright? I'm back up, there we go. Oh, you're missing one slide, Jamie. From an internal viewpoint, what that means for us from how we deliver the app is there are a couple of things of note. Two seconds. I just need to find my slide. Okay. Okay, so from a technical viewpoint, what this means for us is we have 19 unique market apps today, okay? So, every market has their own app in their own app store. And those apps have actually grown from the local teams. And what we've been doing is looking at how we start to standardize the implementation of those apps, okay? The apps are written in a range of languages, both native, so Kotlin and Swift, primarily. And now, more and more, we're starting to see React Native as well. For the 19 markets we have, we have four markets currently live with React Native, three further markets moving to React Native, and the rest remain on native app implementations. So we have a very diverse landscape in terms of technology and the app implementations. Equally, as those markets are serving those markets are serving journeys for their local customers, there are some variances in terms of tooling, STKs, and third-party applications that those markets use within their app. Okay, so there's a bit of a divergence in terms of some of the third-party payment gateways and payment services. Equally, we have some standardization around analytics and those sorts of things. So we have a varying range of STKs included in those. And then what we've been doing in terms of how we start to drive more standardization in those markets, is starting to look at inner sourcing. So with Central Team, we have been working on app implementation standardization. So collaborating with the different market teams to bring about common standards for app implementation. Driving sharing of code, so we can start to share not just ideas, but physical code. And starting to help markets in their journeys from moving from major implementations through to React. So we have a catalog of journeys on RGTHUB repost, and we work with the markets to build those collaboratively, removing duplication, so we build things once where we can. So one version of billing that all markets can take and use, and then we promote those markets, extending those journeys through an inner source or open source approach within Vodafone. We've equally been working very closely with the markets who are moving from native technologies to React native technologies. So for us, the key around React is to gain some efficiencies, so ultimately to build once rather than build twice promotion with React. And what we're trying to do is start to help to learn to change the skills within the markets and give more support for how they shift from native to React native development. So we've been promoting React versions of code. We'll come to know her later on the session who will talk to you about the bridging, which is how we make the React native code work within a native app and overall, trying to bring about efficiencies across all the markets. We just go down to the React native piece, here we go. Okay, so from a React native perspective, I said there are four markets already on React. Three more moving out of the 19 markets we have. Overall, the key driver for that we're looking for within Vodafone is obviously to improve the experience whilst reducing the effort to get the journeys to market. Okay, so stopping duplication, improving the development timelines and also helping with the ongoing lifecycle for the management and maintainability of the code once given, okay? With React native, we have seen the promise being lived to which is rather than building things twice, build it once, it works on both sets.

And whilst we don't get, as you're probably aware, the full, it saves 50% of your time because you have to adjust with the React code to still work within the native libraries and confines and also within the SDKs that we work with. We have seen great efficiencies through the build once using React native piece. Equally, in terms of standardization, having a single code base and a modern code base such as React has greatly helped us to start to remove some of the legacy that we had before.

So, now I will start to talk to you a bit about our pipeline and the tooling we use, the frameworks we use within the React native space. The React native code set has greatly helped us to kind of start to standardize to give a more green field environment for our developers to work from. And certainly, in respect of looking at React versus some of the native coding languages we use, we've seen great efficiencies and gains through being able to do that standardization quicker without so much legacy behind us.

The link to the wider channels. So, we've started to start to use the code that we build in React native for our native web channels. So, for the desktop web experience. So, the journeys that we've built to serve the web have been ported across to also serve the web journeys and working with our web development teams to start to try and say, how do we remove dependencies and duplication, not just within the app space, but also within the wider app and web space and the other channels we serve. And as I said with Albania, we're already starting to move to progressive web applications. So, moving from just a native standardization perspective, through to the web and app and then onto progressive web app eventually. With all of this, we have had some challenges.

Okay, so the skills transition, we've been looking at how we best bring our developers with us in terms of skills moving from their native code base, which is where all of our markets started through to the React native code set and skills that we need. We've had programs of retraining as well as also bringing in new people. It's fair to say that in some markets, we have had more challenges than others finding skilled React native developers, but the skills transitioning has actually been quite an effective piece of work that we've been doing with our shared service center in Egypt and other markets. So, the skills transition is something we've had to take on board. It has caused some challenges, but equally, I think we're getting there. The final point on the skills transition, we have maintained our native developers as well so we still need to have a good understanding of the native code set, the interactions with Android and iOS to make sure the SDKs work, make sure we're interacting with the operating system in a good way and packaging the React native code accordingly. So, extending it a little bit to work with those two slightly different OS device types. From a performance perspective, there was some concern from certain markets around the size of the React native apps versus the native equivalents. We've done a lot of work to optimize the code through the frameworks we use and through the methods and development guidelines that we provide and promote. We've not had any true issues with performance. I think this is one of the things that's been more a fear of markets who hadn't started on React journey yet but based on the markets who have moved to React native and the communities we've established, we've been able to kind of come out with some optimization for the React native apps and no performance issues seen. Equally on the transition approach, we've started to be able to use bridging which NoHel will take you through shortly which is our way of making sure that the React native code that we build can also run in a native app. So rather than having to build a React native version for the React markets, native versions for everyone else, we've now started to build components with the markets so that we build React only and through the use of bridging we make sure that those journeys and code can work in a native app as well. So that helps us get those markets who are not yet fully developing in React native used to the code, used to the frameworks that we use and gain that understanding so they can kind of make a decision on their path to React in the future. Equally from our side where we're maintaining code across markets, having a single version of React code used consistently across all markets means our support processes are a bit simpler and easier.

I'm just going to hand over now to Nohar and Amir from my team. So Amir is the technical lead for the group team on my Vodafone app and Nohar heads up our React native capability in our offshore site in Cairo and Nohar is going to take you through a little bit about the app architecture and specifically about the way in which we've been using bridging to allow our code to work in both native and React native apps. Nohar? Are you able to take control? So the three focus topics that we're going to talk you through in this section is an overview of the app architecture, how we handle bridging and the journey for React native and beyond which we'll talk you through. We were hoping to have a use case from Albania which will talk you through the journey which progresses from app to web and how we share capabilities across the two. So I think we'll jump straight into the architecture section if you have the control of that, Nohar. Yeah, yeah I do. Thank you. Thanks. Thanks, Andrew. Let me introduce myself. My name is Nohar Magdy. I'm a senior technical lead in Voice Egypt and I'm going to build up on what Anir and Andrew said. Let's take a closer look into one of our components, how we built it, what is the architecture and how we build it to be modular. So let's take, for example, a component ABC and check its layers and architecture. The first layer is the UI UX which is built from common elements in foundation. So what is foundation? Foundation is a set of reusable simple modules that facilitate building the UI UX. So it is basic elements that match the UI specifications as modules like our customised text fields, buttons, colours, basic networking and it is a very dump layers no business nor logic in it. Then the second layer is the business logic. The business logic which controls the flow of the components and how it works. They provide the controls and configurations support that will help carry the business logic required to be carried out by the component. And then at the top, you're going to see the mobile app which makes use of this component by sending in the configuration and the data it needs to perform as intended. And as you can see that this architecture of reusable components, when injected in a mobile app, it will result in less maintenance time because it's a set of reusable code. So you have a single source to fix the issue and the vulnerability to definitely more time saved and more efficiency results.

Now, because we are an open source and an open source devoid of home and we're building a usable components library, we rely heavily on documentation. As we call it, it's the heart of sharing our knowledge. And what we do is that we always add the documentation time in our development time rather than something we do at the very end of the development or even worse as an afterthought. But we faced a challenge here that the code was continuously changing and so we had to manually go back and change the documentation. Definitely this resulted in more time needed. How did we tackle this problem? We have our code written in JavaScript and we've added a layer of type definitions to it using TypeScript. And of course, one of the misses out there is that TypeScript and JavaScript could not co-exist in a single React Native project, which is totally untrue. So what we've done is that we've used a tool that's called Typedoc which converts comments in the TypeScript code into rendered HTML or a JSON model. So as an example of a Typedoc file, which has a prop that's called name, that's a string have another prop which is called example, which as it's specified, it's an optional prop and it has a default value of false, and then you have a method or a function on example first, you have a custom type, which is custom type example. When we've used the Typedoc, what do we get? We got this lovely documentation that's extracted and automatically automated or automatically prepared from the code itself. So as you can see, it consists of two parts. First part is the internal props, the second part is the method, and as you can see, the documentation is generated from the code. So it uses the comments that we've added in the code. It also used because example prop, for example, is an optional props, so it added the tag optional and also because we've set a default value the is optional Boolean flag. Then it also says that this is a Boolean flag and the default value is false and it's also optional. So as you can see, when someone looks at this documentation, it's going to straightaway know that for this code to work, I need to send the prop that's called so-and-so and what does exactly what does each and every prop does. So it made it really easier for everyone who's using our components to know what's expected for the components to work and also because this documentation is generated based on the latest code automatically generated based on the latest code that we have on production, this allows us to shorten the maintenance time that we had to do for maintaining the documentation that we have.

Now building on then what Amir and Amber said, let's take a closer look into how we build and distribute our components. So we package our components using npm and we distribute it using jfrog. So what we are doing here is that we're instructing npm to retrieve the packages from jfrog artifactly instead of the default, whether it's your npm registry. So if the desired package is a private package of our own, we hosted it in jfrog repository, then it will be received straight away from jfrog repository and installed locally in the node modules folder. Then if the desired package is a public package that is available in urn or npm, then what happens is that it is retrieved from there, cached on the jfrog artifactory and then it will be installed locally to your node modules folder. Then if you, if this cache package is requested again, then it's going to be retrieved automatically from the jfrog repository, not from the urn or the npm registry. Now a closer look to our CI-CD pipeline for the continuous integration part. We have code in Github interface. We have Jenkins to run our pipeline. We've integrated SonarQube, we've integrated Jest, ESLint. Definitely we're using Visual Studio Code to edit the code and then as part of our pipeline we have lots of testing mechanisms added there. So we have Jest, we have Widesource to check for security vulnerabilities. We have Detox for automating the regression or any end to end scenarios that we have and of course if any defect is found then we raise it in JIRA. Then for the deployment part as I've mentioned we host our packages in jfrog and we take tags in GitHub Enterprise and as part of the deployment when we move code to production the TypeDoc regenerates all of this documentation to make sure that the documentation stays also always up to date with the latest code. Now, as Andrew mentioned we've been trying to add React Native code with native code and it has been a very successful thing that we've done. So we've added the React Native code in a native app and we've also added native code in React Native app. So let's say let's take a look at how we did that. Basically for the first part we're going to talk about how did we add the native code in a React Native app? We have a highly used SDK that measures the speed in all our My Vodafone apps. What we've done is that because this is a highly used SDK that most markets would use, we have picked to React Native using the native module and the native event emitter. This SDK interacts directly with the device capabilities and by wrapping it, definitely this allows us to shorten the maintenance time for this heavily used component. And the cost of maintaining this one component was decreased by 60%, which is a huge time saved for us. Now, one of the challenges that we've faced while adding native code in a React Native app is that we wanted to change the modes to light and dark mode and vice versa. And we've used event emitter to handle this change in mode. So you listen to the code when the change from native, from the native code from dark to light mode or vice versa. And accordingly, the React Native code behaves as well. Now what's next for us on this topic is that we're going to try out the turbo modules, which should facilitate the communication between JavaScript and native code even further. Now taking the other way around, let's see how did we integrate React Native code in a native app. So basically you take the React Native code, you run NPM pack, then you get the.tgz file, you run the React Native bundle command and then you get the.gs file plus the asset. Here's a sample of one of the bundle, here's a sample of the scripts of how do we run a bundle Android for Android. So you just run the command, the React Native bundle, you said that the dev flag is false and then you specify where exactly would you want the output to be, then you get two things, the.gs file and the assets.

These two files are added in any native app and you're going to get React Native code in a native app straight away. Now, one extra challenge that we faced in that case, which is React Native code in a native app, so we had the situation where we wanted to pass a whole view from native app to the React Native modules and we've done that using the require native component components. When you add this small tag above any component when you're describing it in the code, this means that this view could be passed between native and React Native code. As you can see, it's very straightforward, definitely more time saved, bugs just fixed in one place and the efficiency really increased. I hope you all agree with me, thank you.

And handing back to Jamie for questions and coffee break parts. I'll ask it instead. So the question from Peter is, which repository layout is being used, Mono or Poly or other? And if Mono, which tooling is being used? I don't know if someone could answer that for Peter. So I can take a stab at that. So at the moment we don't use a Mono repo setup. It is definitely something that we're currently exploring in terms of how we can structure a project to be able to utilize a Mono repo, how we can detect where changes are being made in that Mono repo and trigger a build pipeline based on that. So at the moment we have a repo per sort of component, effectively, per feature. So in the slides that Noha covered, there'll be a repo for login, another one for onboarding, billing. So for each specific feature, we have a repo and we have a build pipeline associated with that. So that's kinda current setup that we have in terms of tooling, the main tooling that we use in terms of our CI workflows and pipelines is Jenkins. We have a lot of automation within the workflow, we have a lot of scripts that are running to facilitate anything that would be done manually, keeping code up-to-date, pushing code between different branches. So we have quite an advanced setup in terms of CI and structure, but we are currently looking into the Mono repo concepts to see how they would apply to us and how we would manage them across the organization.

And there was just one other question in the chat that I think we could probably cover here from David. And David asks, if targeting multiple SDKs or builds of devices across markets, how do you align with the shared codes that the API is available on a per device basis work? He says, this is obviously a bigger issue on the Android side, more than iOS. I don't know if you, Neha or Emir, would comment on that. Neha, did you want to take that one, or we have to think about that one offline and come back with a typed answer, I believe. Yeah, yeah, let me get back to you David on chat. Cool. Okay. I'll take a note of the question and I'll send it over to Neha so that we can deal with it afterwards. And just one through from Christian. So it says, how do you handle versioning of your code part shared between different markets and API contract changes in them? With a bonus question, so you share TS type somehow? So basically for each component, there is a version that when we add extra features, then we increment the version, whether it's a batch version, a minor version or a major version. And the market has the ability and has the option to whenever they want to upgrade to this latest version of the components to upgrade to. So if they want to stay, for example, if they already integrated version 1.2.3, then they have the option to remain on this version as much as they want. If, for example, I released version 1.4.0 and it has an extra cool feature that they would love to integrate, then they just upgrade to this feature. So basically it's a matter of when the market or when the using app wants to upgrade to this specific version. Do you share TypeScript types somehow? The code is open source, basically, so if they want to check anything in the code, they can. How do we share the output? As I've mentioned in the presentation, the code is written in JavaScript, then there's a layer of TypeScript over it, then the documentation is generated from this TypeScript definition files. So at the end of the day, the documentation, definitely there's two types of documentation that we have. One which shows that for a high level one, which says, for example, when you want to integrate this and this and that, then this is the type of pops that you'd like to send. And then we ask the market to check the parts that's needed for this component to work. We direct them to the documentation website that I've just showed you a sample of. So they are always up to date with the latest TypeScript code that we've written. So, once they've checked this documentation, this is how we share with them the TypeScript text. I hope this answers your question, Christian. If not, please let me know in the chat. Thank you. And then just one other question through on the Q and A. And the question is, forgive me for asking, but why are we using a whole repo per feature rather than feature flags, for example? I can take this one. So, the reason that we have it set up that way is to allow us to release each of these individual features separately. So, using feature flags may take away a little bit from that flexibility or that capability. Most of our features are independent of each other. So, we try and have an abstract set up to allow clarity in terms of which features we are releasing individually. So, we have scheduled releases on a monthly basis, for instance, but we are able to release any component in isolation or any feature in isolation. So, that's why we've set it up this way. As mentioned, when we look at the whole mono-repo approach, obviously this may change, but that's something that we're currently looking into. Cool, thank you, and thanks Abdelrahman for the question. Just a couple more that we can squeeze through, if that's all right, before the coffee break. So, Pizza has another question, which is, is there any API to consume a contract solution being used? Of course, if not, GraphQL, if not what? Do you want me to pick this one Amir? Yeah, sure. Yeah, so in terms of interface to markets, so yes, there's standardization of APIs on the back end, both in terms of the API contract and the data model being promoted across Vodafone markets, conforming to the TMF standard, so the Telco Management Forum Open Standard for APIs. So yes, we are pushing standardization of APIs from a market billing CRM, customer data exposure perspective. Equally, within the app that we have, we do support a certain level of abstraction in the API so we can cater for API variants per market as well. Amir, Noha, anything else to add? No, I think that covered all the points in terms of we try and promote standardization across the markets, obviously every market has a different backend and a different setup. So there is some challenges getting to aligned API contracts, but from a front end perspective, we try and abstract the API contract away from the front end implementation. So there's a layer in between to map the API response to what the front end needs, which allows, obviously, different backends to be plugged in and a level of abstraction, which is really key in this sort of model. Yeah, exactly, like you've mentioned, Emile. So basically, our components are built in a way that they're expecting some data. From where does this data come from? They really don't care and they don't worry about where the data comes from. So whether it's an API, it's a local database, it's a safe JSON file, anywhere, the components are just expecting some data and they want to come in a certain way and that's it. And that's Emile mentioned, we're integrating some of our components with some backend. But again, because each market has a different backend, then we also have the layer of mapping, which is totally override a little by any of the using mobile apps. So if you want to use our mapping layer, which maps the response of the API to our components, then you can. If you have a different backend, then you could override this mapping layer and write your own mapping layer.

So if you want to use our mapping layer, which maps the response of the API to our components, then you can. If you have a different backend, then you could override this mapping layer and write your own mapping layer. Cool. Okay. Thank you. I think just one more question that's just come through from Jamie. Building on Peter's question, what tool do you use to map the response? Is it something bespoke, GraphQL or something else? No, we don't use Graph. I don't... No, no, no. We don't use it. Yeah. Well, it's just web coding. So basically we're expecting the API response to be in a certain way, and then we map it to fit the URL component, the data that is expecting to be in a certain way. So no GraphQL. Yeah. And I think just to David's response on the Q&A. And so that's correct. David, that's exactly the approach that we take in terms of building flexible components to allow markets to have a flexible approach in terms of integration, whether that be against a specific back-end and a shared API or against multiple APIs on their side. So that flexibility is key to be able to support multiple markets with different approaches.

Good afternoon everyone. I'm Pedro Galan, digital engineering manager in Vodafone Spain for WebCMS and Business ID. I'm also a member of the Global Web Chapter in Vodafone. First of all, thanks for joining. It's a great pleasure for us and an honor that you have chosen this workshop and that you are here with us.

So as you can see in the agenda, we are going to talk about web and Vodafone. And we'll do it in three main blocks. First one is an overview about how Vodafone manages web developments in React. The second block will be a slot when we'll explain a set of technical building blocks we already have in Vodafone, really interesting. And finally we'll go to a section we call React in Real Life in Vodafone where we show some of our main projects.

So let's go to the overview. So in terms of overview, I don't want to give you a technical intro or something like that. My purpose is to give you a really brief overview because later on my colleagues will go into technical details. But we think that it can be really useful for you to understand the particular circumstances, challenges, requirements and the goals we have as a multinational company with special focus on our digital channels. And right now, particularly on our web channel as the most powerful channel in terms of sales. This is really important for us.

So let's start with a little bit of background information. As I mentioned before, really useful to understand our starting point and our needs. In Vodafone, we have great human teams with brilliant software engineers. We have a lot of projects and technical solutions along Vodafone. Our large size give us a great human and technical capabilities, but at the same time, this has been causing that we had different frameworks and we also had similar capabilities built in several countries. At this point, the conclusion and the idea is really clear. Let's take advantage of all this power and focus in a common strategy, having common objectives that allow us to be more efficient, more productive, more collaborative, and enrich each other's.

So as a summary, that means that we don't want to have more software built in isolation, so we want, build once and reuse many. So this is something really easy to say, but is not easy to promote, believe me, because we are in this process. So how can we leverage all the things we already have? First of all, we clearly needed a set foundations for sharing and reuse, which are the most important ones for us. From our point of view, there are three, having a common framework, in this case, React, this is obvious, having inner source, so we want to build better than buy, and we need to have a solid base of standards. If we work same way, it will be easy to find and reuse in the future.

So reuse is really good, but we also are taking into account an important point, which is usually a concern for our technical and business teams. And this is to allow certain flexibility for creativity and innovation. Our ambition is not having a heavy centralized delivery model, and we want to reuse, but also to have a space for the innovation and creativity. So we have the assets, we have our main foundations. Where are we right now? So as I said before, we chose React as our common and global framework, and we have a global web chapter in place with a clear sort them target, which is of course boosting reuse. This is the first initial target. For that reason, we created a global web manifesto where we are defining our main principles to reuse and co-create. Of course, the adoption of these principles in a huge organization like Vodafone involves technical challenge that we explain a little bit later. Okay?

So... Sorry. Why did we choose React? I don't want to explain all the benefits React provides. We don't want to do kind of benchmark because for sure you already know this information. Our purpose is only to highlight three of them which are really important for us. First of all, performance. React allows to gain excellent performance reinforced by the MicroFrontend approach and this approach is included in our one web architecture and as you know, performance is a key factor for CO, user experience, CRO and several things that are really important for us and for our customers. The second one, really important is learning curve. We are planning to hire an important number of software engineers as part of our Tech 2025 plan. So learning curve is a crucial point for us. And finally framework adoption. So the app already was the most adopted framework across different markets and we already have some important assets as our source of value, we'll show later. So on the other hand, synergies and reuse between the SDAs for web and be a native for mobile, as we explained them before in the app section is also really relevant for us. So as I told you before, we have a global web chapter and we created a web manifest. The web manifest is one of our pillars because in order to reuse and go great, we should have the same rules, the same way of working. So let me show you a high level view of the main drivers of this manifesto. First of all, we have three main key principles. Building to share first, so because we are not thinking in sharing after building something. So sharing is the beginning, this should be the reason and the main purpose when we start to build something. We should thinking in sharing in the beginning of our developments. The second one is in our source. From our point of view, this is the best strategy to work and collaborate more effectively. A development community working as one team is much more powerful than a collection of isolated individuals. And finally, the standards as codes. So we are looking for commitment, for facts and actions. That means that we don't want only having documents and no more than that. Only the documents is not enough. We need actions and facts, as I said before. We have the principles, but we also have enables to facilitate the adoption. So our Web Manifesto should be easy to adopt because if we are pushing for global adoption, we must facilitate it by being really pragmatic and realistic in the scope. And as the web development is not an isolated piece in our end-to-end applications, we should be fully aligned with and coordinated with the rest of our chapters, DevOps, UX, UI and backends. And this is crucial for us. The software library. I mentioned before this library, we'll talk later about that, but this is the cornerstone for reusing and to create.

This is a really good example of the current asset we already have in Vodafone. We have our dedicated testers for this library conducted by David Blaketon. This is really important for us.

And finally, the roadmap and flak projects. So, knowing the roadmap of the different Vodafone markets is a must. But how can we share and co-create if we do not know the roadmap and capabilities we are going to build together? This would be impossible. So, it's really important to know the roadmap, to be read in advance, to co-create and reuse.

And finally, our third important point is the development standards. Our standards are split into three main categories: general code development practices, web front-end coding standards, and application architecture. It's really important to have a standard, but it's also really important to have some kind of flexibility. So for that reason, all our standards are considered as fixed, flexed, or free. What does it mean? So fixed is something that you should adopt if you want to meet the standards criteria. Flex is something which is highly recommended and you need to have the end of the world. Sorry, will- I think you can just ignore that. Sorry, Pedro, carry on. No worries. I was about to say that free is for us something that which is recommended, but it's not the end of the world if you don't do that. Okay. So those are the main pillars of our web manifest.

So let's go to development standards in more detail. So in the interest of time, because I'm sure that you are more interested in the use cases we are going to show later on. Let me say some examples of our standards so that you can have an idea of the way we are managing this. As a generical practices I highlight the chapters collaboration, really important, and also cyber security. Our application should be secured by design and security requirements should be supported by automated security tools. From the architecture point of view, I will keep this is our software library as I mentioned before, and talking about the standards apart from the version, which is really important read and type versions, it's important also to remark that we have a starters to create different border rates depending on the use case we need. So we also include in our standards estate management with Redux, and we propose micro fronting architecture bus but as a flex standard. Not fixed in this case.

So, and now, where we are, what we are looking for. So, this is like, tries to summarize what we have and where we will follow in the example of a house. So the foundations are the assets and capabilities we already have, our development community really powerful, our common framework which is React, our standards and web manifesto or all our local and global projects and assets. And of course, our technical building blocks already in place. By the way, our technical building blocks are really interesting. They will be presented by some later on. So, on top of our foundations, we have the pillars to leverage them with the purpose of working as one big team and be more efficient. We should adopt our global standards on the markets, we should have the mindset for building to share first. Of course, all new developments should be based on our web manifesto. And as I mentioned before, we should have a clear idea and alignment on the roadmap, on the different Vodafone markets. Finally, on the house of the rule, we have our purpose, our target or in other words, the benefits we're looking for. And those are increased quality, reducing time to market. And because of reducing, we can have economy of scale, so we save a lot of time and cost. And if we want to have the proper standards in our purposes to that the reuse is really easier across channels and markets. So having a proper reuse will reach an economy of scale and we increase our quality reducing our time to market. This is not an easy task, so we are also facing some technical challenges in the way to achieve our vision. So I'll explain next slide our main technical challenges. Sorry. We have three main technical challenges. The first one, the most important one is different develop frameworks along Vodafone. Vodafone market use different JavaScript frameworks, Angular, React or even Vue. And this is limiting the reuse across WebData Engineering team. During this workshop, we show you our technical solution based on micro front-ends for the co-assistance of Angular and React journeys in a legacy Angular application. This is really interesting. The second challenge for us is the legacy and new developments co-assistance. So, because when we are talking about legacy, it's not only a matter of different frameworks. It's also about all source code or all UX UI designs not aligned with our web manifest and standards. And our commitment for adoption is that all new developments must follow our global standards. But what about the legacy developments? So they could be upgraded, but these will be always optional because we don't want to impact in the business road map. And finally, the third technical challenge we have is UX UI alignment. As you know, UX UI designs are the starting point of the web development. And sometimes those designs are not based on local standards and this is limited in also where reuse and standardization. So, one key point for us is have a clear commitment of the business units to have a common design, to have common design guidelines and adopt them because if we don't have the common UX UI reusing that software developing component is having a commons or whatever, will be impossible. And now I hand over to Sam to explain our technical building blocks. Thank you. Thanks Pedro, trying to take control quickly. Oh, right here. There we go. Hi everyone. I'm Sam Wenger, and I'm a Development Technical Lead within Vodafone business IT. And I'm gonna talk to you a bit about the technical building blocks we use when we build React applications. So we've been on a bit of a journey over the last few years.

So we've been on a bit of a journey over the last few years. A little while ago, every team was kind of focusing on just being the best themselves and working not quite in silos, but focusing just on themselves. We were all striving to use the best tools and processes to write the best React code we could, but we weren't worried about what anyone else was doing. It was all very isolated. We've come to realize that this isn't a scalable model. And so nowadays we look more to build to share first. We want everybody talking in the same language when it comes to React and teams should be able to share their code between one another and anyone should be able to pick up code and recognize what's going on.

And so to that end, we've created sort of three key deliverables over the last few years. They've come out quite naturally and organically. And these are some app starters, app builders and component libraries. So we started off with wanting consistent code and consistent standards. Like any team, we created our own standards initially and we codified these into a doc site. So we used Docasaurus, one of our favorite technologies for doc sites. We like all of our config to be based in readme format. So this meant that it allows us to sort of copy and paste the code between both our native, our actual applications. Sometimes we include documentation in the apps as well for standards, but also it means it's very easy to add more documentation whenever you want. We created this and we wanted to share it with others. So first of all, we tried to build it out properly. We made sure we had lynching rules in there, the tool sets we use. For example, we're very keen on things like ESLint, Prettier, commitlint, Husky, Jest, all those good things to make sure our code is the best quality it can be. And we wanted to share that with other teams. So as Pedro mentioned a minute ago, we decided to talk to other teams and came together to make a manifesto. And this was essentially an agreement between as many teams as we could get on board to define standards. Kind of like a level above the actual coding standards, but referencing to them of ways to work in when coding a React app, and then any app in fact. So we agreed on things like how to build your code, how you should try to make things abstracted so that they can be shared, how to synchronize other teams. We created a front-end development guild to invite anyone to come and share what they're doing and how they're working so that we can all collaborate together. And then more obvious things like some of the tool sets we use. In our pipelines, we tried to use things like Lighthouse for accessibility and SonarQube and Whitesauce, code quality and security. And again, we were trying to get people to align on these tools. So we put all of that into the standards. Now we didn't want to dictate to teams how to work. It was quite important that this was something that sort of made everyone's life easier and better rather than something that was just one team came along and said, this is how you need to work because we knew that people would rebel against that.

So one of the things we started out building was app skeletons. And these are just standard starter app type projects that sort of any lead or senior developer will have to create at the beginning of a project anyway. It's just the bare shell of code ready for anyone in the team to use. And we baked into that as many standards as we could. So it already has things like our Husky hooks on commits and pushes, jest config, ESLint and prettier config. All those good things are put in there from the word go. And we also added things like Docker files with configuration on good security within Docker because not all teams know how to use containers and yeah, just all the config and stuff we could bake in we did. This was quite useful for teams to pick up and check out. It's just a GitHub repo as a template. So anyone can clone that into their own repo but we decided to take it further and we also built the initial app starter project. This is just a react application in it's own right with a little Java API behind it. And all this does is picks up those exact templates, those GitHub project starters, but it adds a layer on top to allow a developer to choose the options they want when they create their starter so they can pick certain libraries or if they want a mono repo, it will automatically create the mono repo sets up for them ready to use. The same with module federation. Some teams have found it very difficult to get things like webpack's module federation feature working in a mono repo. Whereas other teams that like ourselves have done that a few times and know how to do it. So we built a starter for that that allows anyone to get a working model straight out and then they can just worry about adding in their own code.

Next we wanted to focus on how we can improve the way we build our code. So we found that especially in Vodafone business, we build a lot of repetitive forms. There's a lot of just the same components that's essentially a different configuration with different labels. And we wanted to kind of speed this process up. So we created what we called the dynamic journey language. And all this is, is just JSON configuration. So you can see it here. It's just structured config that describes a react application. We mentioned the components, you have children, you have props, and then there are custom keys in there that we use for other things. And it is very basic standard JSON schema, but it combines with something we built called the dynamic journey renderer to automatically build out the UI layer of your React app. Now the dynamic journey renderer is a very simple little library on its own. It's only 75 lines of code. And it allows you to, essentially iterates over this JSON schema and renders the React components. And it allows you to extend it with plugins to actually perform business logic that you've coded in your app. So within your code, you put in hooks like maps data props, or API calls, and you code that business logic in your app. And then you use this schema to define how it should look. And an example of that's about to pop up using our original version of the app builder sort of proof of concept. What we were going for here wasn't a low-code platform as such. We didn't want to just create a tool that's meant to do everything for you from the word go, because sometimes people really do need to get into their business logic. And also it wasn't our team's remit to do that, but it allows you to create that JSON schema really, really quickly and turn it out, ready to push into an API, for example. What this will do is allow you to deploy your application and pointing it to JSON schema have everything that actually handles the view within an API.

What this will do is allow you to deploy your application and pointing it to JSON schema have everything that actually handles the view within an API. And that means that you don't have to do the full deployment cycle if you want to change just the ordering of some items on the screen or labels or things like that. This became the baseline for what is now known as the app builder, which Marwan and the retail 10 team are gonna talk about in a minute during the use cases.

And finally, we had our component libraries. So we started with a style guide. We have what's called Web Simplicity. It's been around for a while in Vodafone, it gets modernized every year, and all teams are meant to follow the Web Simplicity style guide. Like any reactive element team, the first thing we did from this is turn it into a component library for easy reuse. We tried to do things that were best practice. We used a comic design principles, we made the components as dumb as possible, just visual UI layers. And when we finished, we were really proud of ourselves. So we started talking to other teams to see if they wanted to re-use it. However, what we discovered was actually other teams that had the same idea. The first thing we spoke to had already built their own one. And actually they'd been building it before we started. And then while we were working with them to see if we should maybe unify, we found another team had built one. And every time we spoke to another team, we found that they had also built their own component library mostly following the same principles, a little bit of variation. And sometimes the styling had been customized for that market, but at concept, we'd all been doing the same thing. And there was a lot of code re-use and duplication of effort across the markets. So we decided to come together. And as part of the Web Development Guild, we tried to get as many teams as possible to come in and agree on one library to rule them all. One single source of the truth, all component libraries. And this is what became the Source Web Component Library. And I won't go into any detail on this because David Lindley's about to talk about this in the use cases.

Okay, thank you Sam. Now we are going to explain six project initiatives we have along BoraFone. And we'll start with our Source Web Library. We are mentioning several times in the presentation. Now is the time to detail Source Web. After that, we have a view on marketing pages in UK based on headless CMS and the way we are allowing a container to start their development content with no need of deployments. This is really interesting also. And third place we'll have a view on Retail10. Retail10 is our platform for building and integrating React micro apps especially for retail channel but this can be also used in other channels. After that, we will have a view on the SME portal in Budaphon, Spain. I'm trying to explain the way to guarantee the ecosystem between Angular and React based on architecture, module federation or micro contents. After that we'll have a review on a really important project in Budaphon which is Marketplace in Turkey use React for creating a web view integrated to our mobile apps. And finally, from Italy we'll have a view in the new architecture for a new project based on the web manifesto. And they are defining a new architecture in Budaphon, Italy trying to leverage all cloud capabilities and boost performance and the using based on cloud adoption. So now, David, whenever you want to start explaining it a little bit.

Thank you. Brilliant, thank you so much, Pedro. Well, good afternoon, everybody. My name's David Lindley and I'm a software engineering manager here at Budaphon. And I'm also the technical product owner for SourceWeb, which has been spoken about quite a lot. So we'll start our journey into what SourceWeb is and why we use it. Great. So what is SourceWeb? Well, as Sam pointed out and Pedro has talked about already, it's our global component library, bringing all those other component libraries together, working on the best practices and making sure that we have one centralized source of truth for the way that web UI looks. It's built on our sort of design system, which is called source. It's large, look at the stats on the slide. It's got 220 components built using atomic design principles split into from the smallest atoms, such as buttons, all the way up to organisms and page layouts. It's used by about 350 developers. That number grows daily across the globe, basically, across Vodafone. And that's only within a year, we've only been going for about a year with this project. This product, as I like to call it. It's had about 27,000 unique downloads. So that's, you know, pipelines, individual machines downloading this to use it. And it's used by six markets and sub-brands across Vodafone. And when I say sub-brands, those are brands that are Vodafone owned, but they don't look like Vodafone. And that's quite important when we come to look at the technology stack going forwards. So if we look at the tech stack, go to the next slide, please. Thank you. The tech stack here, unsurprisingly, we use React to build our components as this is React Summit. We do use TypeScript as well, alongside React, similar to the way the app does. We use that mainly for the props. It allows very easy integration if you're using TypeScript in your application. So you can see the props very easily. We use style components. That allows us to theme our components so that we can provide sort of a color layer, a spacing layer, a font layer, which allows it to be used by sub-brands.

We use style components. That allows us to theme our components so that we can provide sort of a color layer, a spacing layer, a font layer, which allows it to be used by sub-brands. Similar to how material UI works. We have a public face of a doc site that's publicly facing internally, which allows people to see what's available, and I'll show a demo of that in a second.

There is a mono repo. So we use Lerner to do our package management with every component being individually published and versions, so we can easily maintain control of what's changing when, because it's open source inside Vodafone, we want people to contribute to it. It's not just my team that develops this. It's 350 developers plus can come in and modify this code base.

We have a real focus on testing. So we look at jest and enzyme. We are looking at React testing library as well for unit testing. And then towards the interaction testing and integration testing, we're looking at Cypress, Cypress X, and something called aptly tools to do visual regression. And a lot of that is automated. So we automate our visual regression. So if you spin up a new component, we generate a brand new Cypress test for you so we can easily check it in our pipelines.

This is a little video here of how SourceWeb looks. We've really focused on making it a shop window. It's not just for developers, it's for product owners, for stakeholders, anyone who's really interested in what's available for the web. The idea being, if we make it easy for people to view what's there, they can click on things and have a look. So this example here, this is an accessory card. We might use it to sell accessories for phones. And you can see live examples of changing the code live. Again, you could potentially build up an application in the docs site using this. This uses style guide is behind under the hood but we've customized it heavily to make it look as you can see on the screen now.

We also showcase props and documentation and we also link to Figma, which is our UX sort of platform so people can see what the component should look like and how it should be used from a UX standpoint so UXers can also interact with this. We also have theming. So as I said before, you know, you can use this with sub-brands. So we have a couple of themes in Vodafone already but I'm going to quickly show on here, this is a theme that we have which is called Voxy, Voxy is a sub-brand in Vodafone UK and they use some of our components to quickly build up applications. They have a much smaller development team than the Vodafone UK development team does and so they utilize this library to very quickly develop stuff and get stuff into production. You can also see here, you know, we've got two themes under Vodafone as well. We also are very keen to ensure that we do good documentation. As Sam was talking about, good documentation is really important when it comes to global engineering and so we put a lot of effort into writing really comprehensive documentation. We make sure it's updated regularly and this is to encourage people to contribute to this library. As I said, you know, this could be used by 350 people from different markets across the globe so we need to make sure that there's a really strong documentation behind it.

Get to the next slide, please. But it's not all been plain sailing and I want to focus on three, three things that have caused some pain to us as we've gone through this journey. Some technical challenges that you might be able to take away if you are building a monorepo or a component library up in your organization. So the first one is the number of changes. So we have, you know, we could have 10s, 20s, 30, 40, hundreds of changes happening every day in this library depending on the need of the market and the consumers. Bugs, new components, changes to the documentation, and as I said before, we've got such a focus on our testing that we initially were finding that our pipelines were becoming absolutely chock-a-block. We have shared pipelines to do all automation of our testing, and a full regression suite of all our Cypress tests could genuinely take about six to eight hours because of the number of components and the number of different things we want to test with them. So what we looked at is, well, how can we optimize that whilst also maintaining the quality of our tests and the confidence in what we're delivering to the consumers? So using Learnr and knowing that we are a mono-repo, we were able to build a dependency mapper. So we could easily determine what to change based on the package versions that changed. On the right, you can see a little bit of pseudo code that we wrote, but this sort of gives you an indication of how we do it. We go and use Learnr to determine what the current package JSONs are in the library versus what's published on NPM. And then from that, we build up a dependency tree to work out what has actually changed. And then we only test what's changed. And this brought that six to eight hours testing cycle down to about 20, 30 minutes for the average changes that are coming into the library. So a huge change and a huge optimization.

Second, we have being a mono-repo. So if we can click through. So being a mono-repo means that keeping the library healthy is quite challenging. The number of packages, 220. We want to make sure that every time we publish a change, the whole library is up to date with the latest change. If a consumer downloads the whole library or wants to download the latest of everything, everything works seamlessly with each other. So this initially was fine when we had like 50 components, not a problem. As this grew, this became a really difficult task to sort of keep going. So what we built and what you can see on the screen is a CLI tool that basically allows us to quickly update all the packages that are dependent on other packages. So in this example here, I'm updating the button, which is used by lots of components. I'm updating it to a patch. And it goes then and works out what components consume that and then what components consume that, et cetera, et cetera. So it becomes a dependency chain again, which means that that change that could take hours now takes, well, 30 seconds using a CLI tool.

And the final learning that we've had through this is consistency. Consistency from a UI UX perspective, but also just from the way we code. Sam talked about those standards and Pedro talked about standards. And this is really critical for a shared library to have those standards embedded as well, because we could have developers from loads of different backgrounds, different sort of way they've learned to code coming into this library wanting to contribute. And so we want to make it easy for developers to use it. So what we created was another CLI tool, and you can see it on the screen now, which basically generated us automatic template files for components. So it talks you through how you build out a component, is it an atom, a molecule, an organism? Where does it sit? It even asks you things as, do you want it to be a class-based component or a functional component? And it'll generate you all the files you need to get started. It will also lodge it in the Docs site, so you can see it when you run the Docs site locally. And then it'll also generate automatic tests, which I talked about earlier. So you can see here we're just choosing the theme. We're deciding now whether we want it to be functional or class-based. Most new ones now are functional. And it generates those files for you, and then what it's gonna do is automatically generate Sitepress tests of all the components. And basically, this means that your brand-new component you've just created, you haven't even written a single line of code, automatically has a Sitepress screenshot test of a dummy component. But at least you have then a template to go and modify and update. And that's how we keep consistency. All the files we auto-generate have got comment blocks in them ready to go, so consumers can follow a pattern. And this obviously goes alongside with our linting rules and things like that as well. So hopefully this has been a little bit of an insight into SourceWeb, some of the challenges we've had, technical challenges, but also the benefits it brings. Being shared, we really encourage all teams, all new web applications, to use this library going forwards. So I'm now gonna hand over to Anna, who's gonna talk about web marketing.

Hi, everyone. I'm Anna and I'm a software engineer manager at WebAppOne UK, and I'm looking after the team that's building this platform I'm gonna talk to you about, which is integration with Contentful, which is basically a platform that has a CMS and allows our content editors to create, for now just marketing pages, but the plan is to actually integrate this with every other part of our website. So practically saving content for every part of the Vodafone website without even needing to do any deploys.

Okay. So here I'm gonna show you like what you see on the screen of what we build. And just to go a bit of like in details of where we actually use React and how we actually been able to integrate that with Contentful is, after we get like the content from Contentful application, we build like a pipeline that goes through some lambdas and some messages. I'm not gonna tell you about that part, but we have this lambda that practically is adding in all those pages that we will render on the website, is adding some root component that is bundling the actual content from Contentful with our application, with our code for our components.

What we do then is we are actually bundling everything and saving the static assets, the actual build JavaScript into S3 buckets. So we save our static pages, bucket is only having like HTML and some data fields that we include the data from Contentful and then we have a page assets bucket which includes all the JavaScript images and everything else you need to actually render. Now, we are rendering everything server side rendering but we do use SourceWeb components and that's why you can see here we have the SourceWeb components. So what David just presented, our CMS platform is built entirely with SourceWeb components so we don't build anything bespoke and that's also mainly for alignment. So here I'm going to show you I've told you about the root component that we are adding it on the page. So here you can see the way we do this. So whenever we get these messages about new published pages or Contentful by the Content Editors, our application is adding and creating this page by adding its root shared wrapper. It has a team as you've seen in what David shared like the, we have two teams for our source web components. It has the assets location configuration which is the bucket where we get the actual code for the components, the environment because we build in different environments for developers to actually be able to test it in lower environments or dev environments. And then we have a CMS provider which actually gets all those properties that our content editors will put in Contentful and maps the with the properties from source web. And next is CMS provider is actually loading that data that I told you about. Then I wanted to show you like how we actually map those props. So you can see here that for Content Block which is a component in source web, we get the data from CMS and then we are going to audit as properties which then are sent to the component from source web. So the source of just gets the data in the properties with the properties they expected and we do the mapping from the content full properties. And the last, the last component I want to show you is the banner cursor. It's a component that we use in a lot of our pages. And what we do is make sure we get the CMS data as I specify in your CMS fields, getting the data and mapping that with the actual fields or properties that the banner is expecting from the source web. And at the top of that, you can see that the banner is imported from the package source of this publishing when they actually publish those packages. And that's it for marketing pages. If you have any questions, let me know and I will hand over to my colleague, Marwan.

Hi, good afternoon everyone. My name is Marwan Druby and I am the Technical Product Manager for Retail10 working in the Retail and Web IT within Vodafone group. So I think our user case, we're gonna work around what's Retail10 so you can understand why we built the App Builder. So Retail10 is around transforming the experience for our agents and stores across all our 22 markets and enabling them to have additional experience with side-by-side selling for agents but also enabling mobility on tablets and enabling self-service on kiosk. And we build the front end using React but we have a challenge which is we need to work for, build for all our markets. I'm trying to move to the next slide, yeah, we need to build for all our markets but we want to be able to allow all of our markets to configure and build their own apps. We also wanted to set the challenge for ourself where something is built in Germany can be used by another market like Greece and Spain and they know that this component would work. So we built the App Builder which is an ecosystem that takes into account all of the things that Pedro, Sam and David talked about earlier. So we took the source web, we take the DGR and the app starters, we take the DevOps and the web manifesto and we combine them in one ecosystem to build apps. So it's, the way that I described is like a factory. So you have your raw materials which is your source web components and a marketplace of configurable functional widgets which they are React applications. They are React application developed like any other application. But also you need, this is the presentation layer which is as dumb as possible. You have your API catalog library of ABIs that you want to import the swagger file to and you need your own custom logic and saggers to bind them all together. And what the app builder provide you is provide you is common capability for all this components to drag and drop and build them into a pages, choose a boiler player for your core app whether is a symbol BWA or actually you can even use a react native as your core app to login all your components. And every components is built to be configurable because markers are different. So I give you an example of that. It just a customer search in Greece is based on a tax number in Spain is based on billing ID. So you don't wanna build two separate components. You just wanna change the look and feel of the components and the ABI mapping for the same component for the two markets. And they can do that through the app builder and through the pipeline, it's maps and integrates all of these components together and deploy the app either on a S3 bucket or actually on a product companies. So why we did that? It just allows us to have a faster time to market. It allows us to have a really rich configuration. We can show you through the video how you can change the components on the fly using the DGR that Sam was talking about. That marketplace allow all of the developers to see what other markets have. So you can see all the components from the UK and you can use them in Germany. You build them once and deploy them many and everything is facilitating standardization. Even though we say it's a low code, it has a two mode. So you can build everything from scratch as a drag and drop. But also you can create a boilerplate from a boilerplate for a component, create a React application with a full cycle development and then integrate it into the App Builder. So it allows both types of both modes of development. I'm gonna hand over to my colleague, Muna, who's a technical architect for the App Builder, who's gonna talk about that widget development life cycle, and then we're gonna go through a short video about creating and deploying an application. All right, thank you, Mehran. Hi everybody, I'm Muna Youssef, Senior Technical Lead in Retail Tan. Okay, so here I'm just going to walk you through the main components in Retail Tan. So as Mehran said, the App Builder is a low-code development tool which enables the user to create and design pages by drag and dropping UI components onto the pages, thus maximizing the scope of what can be done through the UI. But the goal was never to forgo the need for actual code. A local market could develop components and share it with other local markets for use. To facilitate this, we have a widget template with the layout and the structure for the widgets. It resides in a GitHub template repo. It also has the boilerplate code needed for the widget to function properly, like a configuration file, a props file, a ReduxReducer for the widget. Also, we have another file that mimics or mocks the actions from other widgets that could be integrating with our widget. When our widgets get built, we push it onto a Nexus repository. To ensure also the same look and feel as other digital channels, we're reusing the source web library that David walked us through in previous slides. The app build.front-end fetches the widgets from the Nexus repository. And it displays the widgets next to other digital assets in the marketplace. These digital assets could be atomic components. We have this graphical editor in which the user could design BPMN, which stands for Business Process Modeling and Notation Diagrams, which represents a minimal viable subset of Saga concepts that could be dispatching an action or calling an API. The app then will be generated with the correct Sagas produced for it. For this, we're using BPMN JS library for this. There's a app builder API for storing and retrieving the apps along with their configurations and translation. The React app is a React PWA, which is generated based on an application template that resides in a Git repository. The app building process is initiated by a builder, back-end invoking a Jenkins pipeline which retrieves the application template and then calls the code generation mechanism. This code generation mechanism calls app builder API to retrieve the apps along with the programs and settings before generating these files. We're using handlebars which is a template engine to build the JavaScript files for our app and the dynamic journey under files for the pages with which Sam walked us through in previous slides as well, which will ultimately get deployed on a Kubernetes cluster. Okay, so next, it's a demo video. Okay, I'll just, okay, next. Okay, so we'll start with the Widget Development Lifecycle. This is the GitHub template repo that we talked about that had the layout and structure and the boiler plate code needed for the widgets. We're just creating a new widget. Okay, so next, I will update in the package the JSON file of the widget. We'll set the name and the version for the widget. This is how the App Builder identifies the widgets. We're also going to set a category for it. I think that the App Builder groups widgets by category and when displaying them in the marketplace. Okay, and we'll start developing locally on our widget and deploying it. Now we move to App Builder. Okay, so we'll create an app. I will select the type of the app and the platform and the app name. I will select also and the authentication type.

We're specifying a security group for our app. In this case, it's a Vodafone Store agent security group, but it could be any other security group for any types of users. You can also specify the scene. So what David talked about earlier around Voxy. So it shows the right scene for the right library, as well.

OK. Now we'll start designing the pages. In this case, we're dragging and dropping an image component onto this page. We'll add it in the properties of this image component. We're setting the source for it and the ratio. The App Builder also enables us to preview the pages without having to exit the App Builder portal.

OK, this part, in the App API Manager, we're selecting the API and the version for the API we're going to use. Also, this is the graphical diagram editor, which I talked about in the previous slide. We're promoting the app to development. And when the testing phase is done, we could promote it to production, and then it will be available on the web. In this case, this is an app that checks for TV availability in a specific region.

OK, next, what we'll try to do is we'll try to drag and drop the widget that we created at the beginning of this video onto an existing app. We'll select the widget name. We'll search for it. And you'll find it grouped in the marketplace by the category we specified in the package.json. This checkout widget, it appears when the Vodafone Store agent attempts to check out the shopping cart of a specific customer. So now go to the Shopping Cart to be able to check out the shopping cart of a customer and be able to see our widget, Checkout Widget.

OK. We could also update in the configurations of our checkout widgets. But in this case, we're adding a whole new step in our widget. It's a contract download step. And it's a step where we can update a step and we're putting it at the very beginning of our stepper. So when we go back to our widget, we'll see that it's the first step. You can do that without any code change. So you're doing so the configurator section and it will deliver to a REST API. It's called configuration API. So you can change, for example, in this example, you can change a number of steps at subcomponent to the checkout flow and see it live on your application without any change in code. Yep. That's it. Think the video is done. I think there's other sections that we showed, so for every component, all the labels on the components are translatable. So we have another section where you are able to translate all of the values if you're in a different market. What we showed you also in the application that we built for the availability is we took the source web component, we created a symbol availability check ABIs and through the process mapper, we mapped the ABI to the source web components, created the SAC automatically through the process flow and we deploy it on the app. And so that's kind of like the first example where we're using a completely local code. So you build everything from scratch. But the second example is the checkout component is actually a micro front end is a React app. That is built and we're integrating it as a component within a page on the app builder. I think next we'll hand over to Josipa for the SME portal.

Hello, everyone, my name is Josipa Alonso and I work for in the web platform team inside the digital engineering in both of Spain. And I would like to tell you about the solution that we have implemented on SME and corporate web application formerly known here in Spain like EBC. This application is the appropriate originally with the Angular framework. Then we needed a solution to allow us a coexistence with React so that the new units can develop it using this framework. The migration to React was presented as a big challenge because the goal was to begin the immigration at the same time as the legacy app was being maintained. So look at this problem. A problem or first approach was to embed the React app in the parent Angular app and be ad-directive which handled all the apps life cycle and render it directly using react-dom.render. This of course, was a bad solution but has a number of problems. One of them was the performance that was affected greatly because all the code need to be in that and need to be presented when the load that part. So, can I change the slide? OK, clear. So following the WebManifesto guidelines, we decided to go from monolithic application to micro front-end architecture. To achieve this, we went using the Webpack road, using the module federation plugin that let us federate our app into different more manageable modules. OK, to allow them the use of any kind of client we produced it, sorry, to allow us to use their modules this Angular bridge. We put a tab, a component that acted as that bridge and load the Excel of the reactor. This set contained the global reducer store, the routing and other dependencies as the sales library and our old core library that contain everything that was shy between all of the different remotes. OK, sorry. Here's some more technical explanation. Basically when the user makes a request to both of URL, the legacy Angular app was served from our CMS. For instance, all the React modules are static too, but they are in Apache and their remote file entries are all explosive. So when Angular wants to load a React part of the application, he loads this Angular bridge, which then itself consumes the cells remote. This is how the container of our React app loads all the sections. OK, finally, this shell app consumes the urns and data presented has remote entries too. This may sound a little complex. So I will show you a video explaining more details about this. I will see later. What were the benefits for using this kind of architecture? For us, it's easier to deploy new features or to use new technologies because you don't depend on the rest of the app. If one application can go with a different version or version of the dependencies, and we will need, for instance, to upgrade a part to a newer version of React, we don't have to migrate all the application to this new version of React or add our dependency.

Okay? So this is more or less like the backend microarchitectures. We... What? Okay. Sorry. No, no, this is the video. Okay, sorry. We have also the code bases between remotes because each remote is a standard. Although I think this can be good. This can be problematic to scale and to maintain because you are looking to scale an individual component of functionality you will need to scale up the entire by adding more server capacity. For example, in Modifyedition, it goes down to which remote you want to improve. Also we can't reduce the complexity, arising for an unintentional coupling between components that should not know about each other. And another benefits is independent deployment. Every remote, as I said, can have its own continuous integration based on its necessities. The most important one we think that microcontainers are not ideal for smart or smart project or teams, but for large projects and distributed things, okay. In monolithic applications you have horizontal teams that apart from working on their features, they also work on safe components, style, logic, dependencies. In microcontainers you are forced to work on vertical teams in which one team oversees a feature, the other oversees a set of used components and so on. I will show you now the video that our colleague and developer Paul Colomet will show you the details of the code of how this integration between React and Angular is made. So hopefully... Hi, I'm Paul from Bogadfon, Spain. And I'm here to tell you a lot about our solutions to our React migration. So as we've seen in the previous slides, we have two apps that merge into one. Here's the React micro-frontend. The first thing exposed to Angular is the Angular bridge, which is a web component that consumes the root of the app and also handles all the lifecycle between Angular and the React app. Also, it defines this bridge in the window customer elements. So this is the root of the bridge. It's a simple component. It has an object as a probe named angular that receives all the data and function references required for the app to work. And then it loads the shell of the app lazily. We can see the shell now. So this is the bootstrap of the shell. It receives the Angular propes received in the Angular bridge. It distributes them across providers so we can consume them later. Up here we have the component that creates the main layout handles the routing too with the remotes lazily loaded. To make Angular and React history considered. We're also listening for Angular path changes and we are pushing them to a React history. From the Angular side, we are extending the base web to consume the Angular bridge. Then in our bootstrap, we are defining the web component. So this component is acting as the router of the React app. As we can see here, it's over the Angular router and the props is a property of the component that is set to change through the life cycle of the app component. Now that we've seen how all of this works, to create a new remote in Vodafone Spain, we have created a new proprietary generator. So to create a new remote, we just have to input the name. So we can set a new remote. Then it will ask for the port. It will run in locally so we can say it 3009. This will set up for us the new remote, which just have to override the conflicts. And then we can see this configuration. It will set up a simple page. For the remote to work, we just have to add it to the shell routing. So this is a lazy loaded component. And then we can go to the Angular app and see if the component is working. I previously launched both apps. This is React and this is Angular. So to check if it's working, we can just go to Chrome. Let's load the application. So we can open the dev console tool. Let's open network, reload again. So this is the remote entry. That's Webpack loading the React app. Let's log in and if we go to the route we just created, we will see the main page of the remote. So I think it's pretty good actually. This is embedded React in Angular. This is the main app. So this packs it up for me. I hope you've learned something new. Have a great day. Okay. So this is it. Now, Orkan from Turkey will tell us about our key projects for this year marketplace. Hi everyone. I'm Orkan Hallioğlu from Vodafone Turkey.

I am front end development manager. We have almost six React projects at the moment is Vodafone Turkey. But today I'm gonna explain our marketplace project. When we started the project, we decided to coding with React-JS and our other decided was we wanted to use this project with WebView on our app, my Vodafone app. First of all, we launched in October this project and we are using local library for now. And this project is working only on our app with WebView. There is no web version for now, but we will make. And this project working on Apache server. And for now there are 2 million products and 600 sailors and 200,000 order per month in this project. And second part and what's our next targets. Firstly, we will use Next.js for SSR and for SEO. And we will use our source web library with Next.js. And we will use same project on app and web environment. And this project will work on open shift environment of course. And finally now Gizem is here from our chapters and Gizem will explain more detail about this project. And thank you.

Okay, Gizem. Hi everyone. My name is Gizem. I'm working as a front-end developer in a marketplace project. I want to show you some key features of our project but I want to show you some key features. Our project is, we said that our application is only opening in the native app which means that there is no login or customer registration functionality in Marketplace app. Actually, it is not necessary because we built a mechanism which provides us communication between native app and our web views. When a customer logins the native app, the information are hold with their unique field name. In our example, as you can see, when a customer logins the native app, the native app hold this information to send us with the use of unique field names. In that example, we can say that we are holding the client variables with a field name called client variables. And whenever our special web view, which is created by the native app opens we are using session storage to get the customer information, which is going to login in the native app. And then we catch the data of our customer by using session storage. It is up to us how we use this data, how we implement our web views, according to this data. For example, let's assume that a non-model phone customer logins the native app. Then we can also get the data by using session storage and determine which pages or which designs should be seen for these type of customers. Because in our project, we have different types of design for different types of customer. For example, non-model phone, model phone, or postpaid and prepaid, et cetera. So thanks to this data flow, we can personalize our web pages with using customer types. On the other hand, there's also one significant advantage of this data flow. As you can see in the second picture, when we need a device-based functionality in marketplace pages, we are working parallel with the native app. They are implementing a function, especially for the device type, I mean, the customer's operating system. Then we are using these functions which are developing on the, which are depending on the customer operating system. In our example, as you can see, there's a function on the bottom. This function is written by native developers. We needed this functionality because when we try to open the external links outside of our web view scope, there are some limitation for iOS. So while trying to do this operation, we should know and act according to customer operating system. So we are trying to work and developing the function, especially needs customer operating system, we are working parallel with the native developers. Can we go through to next slide? Okay, thank you.

Marketplace is very dynamic and alive application, which means there are always campaigns offers, discounts and classification of the products which are shown in the homepage for our customers. The first picture is taken from our homepage. There is a changeable widget according to special days in Turkey or holidays or special campaigns for our products and we have lots of them. So for that reason, we built a structure to manage these widgets by using our content management system. For example, all the special widgets like in the first picture has a type in CMS, when any technical or non-technical user, of course, which has permission to add products or widget, create a widget by using CMS, adds a special type in that widget and adds the product for that widget. Then our implementation is automatically detect the widget and its product and show in the responsibility web page by calling back-end services and APIs. So that when there is a need to change the widget name or products or title, even the background color of that widget, the only operation is a managing widgets in the CMS. So that means that there will be no development or implementation effort for us in the project if the design will be same for the widget. In the second picture, you can see our categories page with main categories and their subcategories in it. This page is also working with the same methodology. All categories and their images and their subcategories, even though they are popular brands for that category is fetched by using CMS. Then our business team decide to add or remove or edit any category. We are only editing the CMS page for that category. On the other hand, sometimes we could need static page with the static component for customers. In the third picture, you can see our profile page. In that page, there are some components which are content static text like in the fourth picture. These components are also working with the same way. Whenever our team wants to add a new field in profile page, they add a component which contains a text for that component and adds a specific type by using CMS so that as a front end developer, I can understand the type of that component and I can place that component into profile page automatically. Other key point is usage of analytic tools, of course. We are using Omniture, which works as a database for Tillium. It collects our customer data according to current customer events and send them to Tillium to use any other analytic tools. I will show you the code example for that event-based tool. But it is working by event-based using the customer information which is taken from the native part. And last but not least is our search page. As you can see the last picture, we are using Elastic Search. When a customer types characters in our search bar, we are showing the last search text or popular search terms and suggestions for that customer according to the last search terms and text of that current customer.

Can we go to the next slide, please? OK, thank you. And I want to show you the code example that of what I explained. In the first picture, you can see the widgets and component structure of the category page by using CMS. By calling the backend APIs, we are fetching the categories, subcategories, popular brands for that category, and place them into the are components which are implementing for just the category page. In the second picture, you can see a function called uTagView. This function is the call that collects the required data and send it to the Tilium, event by event. For example, we are calling this function while customer adding a product into a basket, or we are calling this function paying or purchasing any products, et cetera. The third picture shows the separation of environment while we are implementing our functionalities. We have three different environments in Marketplace, four Marketplace actually. One of them is testing. One of them is pre-production and finally production. Sometimes we need some configuration according to the environment, for example, CDN. We are using Medionova for crop the images different size for each component type. And as we know that for the performance issue, we cannot crop or modify images in the front. However, CDN based URL is different for each environment. So that's why we have config files for each environment. These include the URLs or our configuration variables in it. The last picture is the example of how we fetch data from CMS to our pages, especially for the static components as we see in the profile page. That's it actually. Thank you for listening.

Hi, I'm Ruperta. I'm the leader developer and part of the Web Engineering team at Vodafone Italy. I am here to show you our long road through our new architecture. The first step of the architecture transformation was the identification of key mitigation action with the aim to simplify the different architecture capabilities and to increase the performances defining an image serving strategy optimizing the JS field and the bundle sides and adopting CDN cloud and headless CMS capabilities. So based on the quick win solution, we implemented a proof of concept that drastically improved the Google vital KPIs of our selected web application. Above all, regarding the web performance to the customer interaction with the website. We did so lcpfid of Google vital KPIs. The poc solution of the Vodafone web manifesto allowed us to define the target architecture. Based on the react and type script where we entirely leveraged on Vodafone digital engineering communities for specific capabilities like monocompo management, static site generation and building scripts. Before going on in details, we selected the use case and capability description. I'd like to highlight the importance of the web manifesto not only for the technical selection but also for standard and code quality with predefined linting and security rules. Usage of UI libraries and experience of Vodafone community in the Headless CMS adoption that allowed us to speed up in the architecture define and definition. Now let's focus on some code as we can see in here. Just putting down the volume. As you can see, you can so in here, as we can see, this is our web application. In here we can see the packages and here there are some commands and then the commands around obviously a different project. Our architecture is based on Nx that is our monorepo package manager. Under app, as you can see, there are all the different projects that we host in our Applash application, so for example, CYM landings, RICE, whatever. And every project obviously has different customization. I see that the video seems blocked. Let me see. Okay. Sorry. Sorry for the inconvenience. Maybe go a slide back and then again to this one, see if it works. Okay, yeah, it is moving, seems like, yeah. Then under leaves, as you can see, there is a little decoder that can be shareable, so in our case, we just wanted to show the themes. The themes that includes everything that can be around the style, so we can have black points, color, front-face, whatever. So we created actually a component, the theme provider, that englobed itself. The video is, I don't know what it's doing. Not correct. Sometimes it's moving back and forward. I don't know why. So we're just saying that the theme provider is included inside the custom app, so every project can have inside that theme provider that can be shared, or just custom for the project. Then, moving on, we can see how Next create the static site generation. In our case we have the HTML pre-render. This is very important to us because, as we can see, the BIF created by Next also have a cache field, and DIR-Nexting, which provide also the path browser for that resource, and fast refreshing development. Okay. Sorry, I'm just trying to stop because I don't know why it's moving back forward. Now in this video we went to the UI part. In the UI part, we just wanted to show you how we decided to handle the image. So we created a component, a leads image component, that imported inside the Next image library. We decided to use image, it is a component from the Next library because it handles quite well everything that concerns the images in Next. So for example, always serve correctly sized image for each device, using obviously a.webv format. It helps with the visual stability preventing cumulative layout shift and also, the important that the image are only loaded when they entered in the viewport which optional blur up the resolvers. And obviously, it's very important that on demand image resizing even for image storage on remote servers. So, as we can see here, we imported in the slide carousel our component image, that takes up, props, an array of images. These images, as we can see, are just uploaded.

So, as we can see here, we imported in the slide carousel our component image, that takes up, props, an array of images. These images, as we can see, are just uploaded. I just stopped the video because of what it's doing. Sorry. In here, I'm just showing a different image. Takes by the array, and then in the web browser, we can see that the image are taking up, first of all, a spaceholder. So they are quite lightweight to upload in page. And, sorry, I don't know why the video gets back. All along. Okay, so in this part, we can see that, first of all, we upload just the placeholder of the image. And then just when the image goes in the viewport of the page, it just uploaded in the right side for that device. So it's quite useful and quite handy for handling images. Yeah, this video is not so good. Well, I'm moving forward myself. As we can see near them. At last, we just wanted to show you, how we decided to handle our CI and CDN. So continuous integration and continuous in delivery with Amplify. This is just the configuration file that obviously points then to the dist already created by next with the primarily rendered HTML static site generation. As we can see near. And the most important feature is that obviously Amplify help us because you can actually create for every feature branch that you generate, you can create a custom development. So every feature can has its environment. This is quite handy for developers because for every feature you're developing, you can have your own custom environment and you can also goes on with your debugging tests to speed up also the development project, the process. And that's it. Most of that is our architecture. So what's next for Vodafone Italy? The next step is obviously to deploy these are new architecture in production and move on with the development. So I hope you enjoyed the presentation even if it wasn't quite strange with the video and the finding useful. Thank you for watching. Have a nice day. Cool. Thank you so much, Roberta, and apologies for the technical issue with the video. I have a feeling that that might be my laptop's fault. So apologies if that was interrupting your following of the presentation. I kind of was able to follow along though. So thank you for taking us through it. I think that kind of brings us to the end. Was there any, I think, Pedro, that was it. Did you want to do any summing up after the web group? Yes, Amy. Yeah, I think that we can do a kind of wrap up to summarize our web presentation. First of all, we are looking for efficiency, we are looking for reusing, and we are looking for greater big development community which allow us to create really amazing capabilities with much less effort than we have in the past. So, as you could see in this presentation, we are spending in several use cases or real applications we are right now in place. So, those are one, a few applications in Vodafone we have much more brilliant capabilities to share and really looking for best developments, best way of working and our continuous improvement is the way we are trying to achieve this. So, thank you for joining and if you have any additional question on web presentation, we are pleased to answer. Cool. Thank you so much. And thanks to all of our panelists for taking us through the demonstrations today. Really kind of rich in content, so it was really nice to see it all kind of presented as one kind of big piece of work. And also thanks to everybody who has watched the workshops. I know it's available kind of live, but will also be watched back. So, big thanks to kind of the participation from the group for asking a lot of really good questions about the content that we've presented. If there are any other questions, as Pedro says, you're more than welcome to reach out to us directly. LinkedIn is probably the easiest one cause most of us will be on there anyway. And I think there's a Discord server from the React Summit itself that we'll be able to kind of post a bit of Q&A results on too. So, we'll do that after the call. Lastly, kind of if you want to learn more about Vodafone, I've left that QR code on the screen again, it's a great link into a landing page around our software engineer journey as Vodafone. And kind of don't forget, we're gonna be at the React Summit. There's gonna be a big Vodafone stand there. A lot of us are gonna be there and we're really super excited about engaging with a few people in the community. Also, there'll be a spot, the robot dog there. If you haven't seen that, it's really cool. So, do come on, have a little look. I think you'll enjoy it. But for now, I just want to say thanks again to everybody who's kind of joined and been on the panel. It's been great to work with you on this and hopefully we'll see you all soon.