Building Frontends at Scale
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 44 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/60214 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Namur, Belgium |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Plone Conference 202227 / 44
10
14
22
23
26
27
40
00:00
Cartesian coordinate systemSingle-precision floating-point formatSoftware developerBranch (computer science)Constraint (mathematics)Physical systemPlanningScalabilityMobile appAcoustic shadowServer (computing)CloningPatch (Unix)Computer architectureWave packetGoodness of fitConnectivity (graph theory)Focus (optics)GUI widgetTask (computing)CodeCentralizer and normalizerConfiguration spaceBlock (periodic table)BitLibrary (computing)Information technology consultingControl flowStudent's t-testAdaptive behaviorProduct (business)Vapor barrierFront and back endsWebsiteDifferent (Kate Ryan album)Error messageRevision controlMultiplication signWeb browserInternetworkingMereologyBuildingFault-tolerant systemInformationSoftware engineeringChemical equationCore dumpProjective planeWeb-DesignerNetwork topologyArithmetic progressionDecision theoryWeb 2.0AdditionWeightRepresentational state transferDebuggerLetterpress printingData managementWindowWeb pageSign (mathematics)Operator (mathematics)HyperlinkFiber bundleScripting languageWindows RegistryMusical ensembleState observerSoftware testingClient (computing)Video gameResultantSoftware repositoryTracing (software)Mobile WebSoftwareMathematical optimizationPlug-in (computing)Functional (mathematics)Element (mathematics)Structural loadFlow separationSoftware maintenanceLinear regressionDisk read-and-write headLine (geometry)Type theoryTemplate (C++)Point (geometry)Data structureUniformer RaumSelf-organizationMaxima and minimaPosition operatorComputer animation
00:24
Turtle graphicsMachine codeStudent's t-testComputer animation
00:42
Different (Kate Ryan album)Adaptive behaviorWebsiteControl flowLecture/Conference
01:13
Library (computing)Revision controlComputer wormMereologyFault-tolerant systemWebsiteWeb browserError messageWeb-DesignerMultiplication signPhysical systemLibrary (computing)Software engineering
02:57
Network topologyCore dumpMessage passingInternetworkingMereologyInformationWebsiteConnectivity (graph theory)Error message
03:38
WordInformationInformationConnectivity (graph theory)Error messageDecision theoryWebsiteNetwork topologyChemical equation
04:09
Fault-tolerant systemWeb browserLecture/Conference
04:27
Function (mathematics)Web browserWebsiteLetterpress printingWeb pageScripting languageJava appletLetterpress printingScripting languageAdditionWeb browserWindowFault-tolerant systemWeb pageComputer animation
05:40
Element (mathematics)Web browserLetterpress printingWeb pageScripting languageFunction (mathematics)WindowArithmetic progressionElement (mathematics)Letterpress printingNetwork topologyFunctional (mathematics)XML
06:17
Product (business)Arithmetic progressionComputer animation
06:50
Integrated development environmentLine (geometry)Fault-tolerant systemProduct (business)Maxima and minimaPosition operatorType theoryControl flowWebsitePoint (geometry)
07:49
Task (computing)DebuggerLecture/Conference
08:05
Front and back endsArchitectureComputer networkMachine codeLibrary (computing)ScalabilityCodeCartesian coordinate systemBranch (computer science)Single-precision floating-point formatSoftware developerBitControl flowScalabilityComputer architectureDifferent (Kate Ryan album)Adaptive behaviorVapor barrierLibrary (computing)DebuggerTask (computing)Focus (optics)
09:49
WebsiteDebuggerSoftware developerSoftware repositoryLecture/ConferenceComputer animation
10:17
ScalabilitySoftware developerMachine codeCodeDebuggerProjective planeMereologySoftware maintenanceData structureTemplate (C++)Computer architectureUniformer Raum
11:16
Maxima and minimaDebuggerTemplate (C++)Identity managementSoftware developerCodeSelf-organizationLecture/Conference
11:52
Windows RegistryWindows RegistryServer (computing)Front and back endsDebuggerRepresentational state transferSoftware developerCartesian coordinate systemMobile appPhysical systemGroup actionControl flowFlow separationConstraint (mathematics)
13:18
Configuration spaceDemo (music)Single-precision floating-point formatConfiguration spaceWindows RegistryBlock (periodic table)WebsitePatch (Unix)CodeBitConnectivity (graph theory)Cartesian coordinate systemWave packet
14:41
RankingConsistencyCentralizer and normalizerPhysical systemConnectivity (graph theory)Library (computing)ScalabilityComputer animation
15:24
Product (business)Digital signalSoftware developerContent (media)Software developerDebuggerPhysical systemBitWebsite
15:48
BitArtistic renderingFiber bundleHeegaard splittingMultiplication sign
16:12
Maxima and minimaVideo game consoleElement (mathematics)Computer networkGraphical user interfaceComputer-generated imageryGraphics tabletComputer iconEmailPlane (geometry)WebsiteTouchscreenContent (media)Fluid staticsHyperlinkRead-only memoryMIDIOpen setMechatronicsMenu (computing)WebsiteServer (computing)Source codeXMLComputer animation
16:28
State observerError messageComputer animation
16:44
Gamma functionVideo gameError messageProduct (business)Physical systemComputer animation
17:02
Computer-generated imageryService (economics)XMLComputer animationLecture/Conference
17:19
Front and back endsFiber bundleMathematical optimizationResultantSoftwareMobile WebLecture/Conference
17:49
Turtle graphicsBuildingScale (map)Fiber bundleConfiguration spaceFlow separationStructural loadPlug-in (computing)Library (computing)ResultantLecture/Conference
Transcript: English(auto-generated)
00:15
Yes, checking. Yeah, it works. Hi, all. My name is Nilesh. I work as a front-end developer at Aude Web as a consultant,
00:23
and I'm from India. I started to work with Plone and involving with the Plone and Volto committee in 2018 when I started as a Google Summer of Code student. And since then, I'm contributing to Volto Core and sometimes also in Plone.
00:44
So the talk will be about how do we generally scale front-end products, how do we adapt micro front-ends, and what's the difference between monolithic and micro front-ends, and how do we use it in Volto.
01:00
So resilience, so I'm going to talk something about the resilience. So resilience means something which, like if you want to develop a website, then we want to make sure that if the website sometimes breaks or the error comes in the website, then we need to be there for rectifying these errors. So we need to make sure that the website will build,
01:24
should be an error, it should not be an errors website. So why do we need it? So we want to, we have to account odds. If there is an XHR request, if you want to make sure that if you are using a third-party library, then that third-party library is maintained well.
01:42
And also if you're using the ECMAS ES6 versions, or ES8 versions, we want to make sure that these versions, they are supported in the latest browsers, otherwise we have to use polyfills, other things. And also we have to account user behaviors, like a user should not, a user can click a button which submits a form, and if he clicks the button twice,
02:04
then it should not be multiple, two times the request. So we have to account for these things. And the other two are the graceful degradation and the progressive enhancement. They are the two software engineering concepts which we use generally in web development to build website.
02:22
I'm gonna talk about it. And also brand perception, like if we are building something that really means a lot, then we should be take fully ownership of that. Yeah, so grateful degradation. So the name suggests it allows the system
02:41
to continue working if the parts of it are dispersed. So what that means is like we want to build a website, and that website should be, the features of that website should be degraded gracefully to up to some amount in the older browser. So let's say if we build something for Google Chrome or Firefox,
03:01
then at least the basic features of that website should also work in Internet Explorer, so that we degrade the features gracefully and to support some basic parts in some older browsers, like Internet Explorer or something. So normally it's a good practice
03:20
that we usually hide the degraded component. So in a website there are, if you see the glance, there are two parts. One is the most primary information and the other is the secondary information. So if the error occurs in the most primary information, then we notify the users. Let's say if we have a bank website
03:42
and if we can't even fetch the balance, then we should notify the users that, okay, the balance can't be fetched right now due to some reason. But if there is a secondary information, like let's say the notification, then at least we should hide the degraded component and we should not throw the errors
04:01
because it's a secondary information. So it's like a decision tree. Progressive enhancement. So it's also a methodology which is, you could say it's opposite of graceful degradation. So it's just opposite, like we enhance the features.
04:23
We start from the very basic and we'll support that feature in all the browsers and then as soon as we go to the latest browsers, we add more features and those features are supported in the latest browsers. So basically we increase the addition of more features
04:42
which are supported in the latest browsers. It's opposite of the graceful degradation. So a small example of what we have. So we have this print, this button, and we created this anchor tag with a JavaScript.
05:01
We're using the pseudo and window.print. And so we can have several consequences, like what if the JavaScript is disabled there? So user don't know, he also don't know how to enable it. So we can have a fallback. So in the next page, we can add a node script tag
05:22
and we can notify the users and that printing this page requires JavaScript to be enabled and it should please turn it on your browser. But that will also account if the user, they know how to disable it or enable it. So these are just, I would say, a nice thing
05:42
so that we can, we should at least notify the users. This is a technique, so here we should not, like we do not bother in the progress even as we do not, we do not bother about users, whether he knows something or not. We just check if the print function
06:01
is available in that browser, then we'll show that element, we'll append that element in the DOM tree and then we can append the handler into it. So if the feature is level, let's use it. So it's like this. And yep, so graceful degradation,
06:21
progressive and when they are the just two, I would say techniques which we can use it like either. So they comes with their own pitfalls and their own requirements. So graceful degradation, if we have the less manpower resources for a company to support the features which are less supported,
06:41
I would say so we use that. And also if you have a critical product in which we are, which can be vulnerable to a risk, so we can adapt this technique. Also it can be sometimes technically challenging to use the graceful degradation. In the progressive environment,
07:01
we build us a basic product, we build a basic website and then we can add the features like line by line which are supported by the newest browsers. And yep, so yeah, like the greatest deal per se
07:21
that have the best type of weather is one that doesn't happen. And it's a nice thing we should also account like what can be the breaking point in our websites. So also this pessimism is overplayed optimism, favored resilience. So like we should at least make sure when building something, at least a solution,
07:41
a minimum viable product that works. After that we can just focus on optimizing this. So at least we should favor the specism or positivity. Yeah, this one I've discussed like you guys should not be punished if you do some irrelevant tasks so we should also account for that.
08:03
A monolithic front end. So I'm gonna talk about some monolithic front end. So a monolithic architecture is something which is singular, which we develop on a large scale and it's a one code base that rules everything. And let's say we put everything on a single code base
08:21
and like we run the development there and we also adapt the trunk-based development. So trunk-based development means like we have a branch in which we commit all the code and then there's another branch which is only used for the release. Then we can just, whenever we're going to do the release, we can just merge the other branch into the main branch.
08:47
Also we can automate the repetitive and redundant task to help the development teams focus on pushing the efficient code. So there are also some disadvantages to monolithic front ends like because we have a single code base
09:00
and everyone there working on a single code base so it can also have the slower development speeds. Also because the single code base then it's a bit difficult to scale it. So it's also not reliable because if it is a single code base then if we add a library then it can break lots of things in that.
09:21
So if you have a different code base then it will help a lot. Also the technology adaptation barrier and the flexibility because we have to make sure that the new libraries and the new tools which we adapt that should be supported by our APIs.
09:42
So how do we achieve resilience? So we have a few methods which will help achieving resilience in our applications and maintaining the scalable code and scalable websites. Let's talk about Volto. So like how do we do it
10:01
and how do we manage it in the micro front end architecture? We have the main Volto development which is running on a repo and we have the add-ons which develop and which we deploy on another pipeline. Code maintainability.
10:21
Let's talk about the first part of achieving the resilience in the code maintainability. So we have this micro front end architecture and the component-driven development which we can use to create the scalable front end and we have to make sure that the code we write is maintainable in the long run
10:41
and also we have to make sure that we have a developer and the resources to inculcate on the repositories and on the projects. So on the code structure if you see we want to make sure that if we develop some templates or then that template should have the same structure so that a new developer who comes in
11:02
he knows that, okay, this is the place and these are the things it should have and it's been easy for onboard new developers with the same code structure, at least in the templates. Also, yeah, we have the uniform code convention and coding guidelines in our organization.
11:24
At EEA, so I work at EEA. We have Volto front end template for just generating the front end code and that template has the identical development tools and we have the add-on template and also in Plone, in the main Volto
11:42
we have the generator templates which is also awesome. Let's talk about the second thing like the micro front ends. So micro front ends are the small application which we can develop and which we can combine and the last group delivers something which is special
12:03
and we develop and deploy these things individually. So what are the advantages of the micro front end? Like apps are small and independent so they are not closely coupled to each other so that if one of them breaks then it shouldn't be dependent on the other one so the separation of concerns.
12:21
And so every app does this whole thing so it should not be dependent on what the other app is doing and it's easier deployment. Like in EEA we develop add-ons and we deploy it individually and that's separate from the whole Volto. Also it doesn't have the constraints on tooling and infrastructure and easy upgrade system.
12:46
Yeah, a small workflow of like how do we use the micro front end. So this is the Plone which is having the application server ZOAP and Zio. So it's a Plone which handles, it's a backend
13:01
and from Plone talks to the REST API, talks to Volto through a REST API and from Volto we have the two front ends like that Volto development goes on a different pipeline and then we have the add-on registry which couples all the add-ons and then these add-ons they develop individually and they are released individually.
13:25
Yeah, we have been talking about it a lot since the last conferences so it's something which Volto like really, it's a nice feature which Volto has. It's like a monkey patch. We shadow component which we want to patch and we just, we have used it in trainings
13:44
and it's pretty much good things of the past. Yeah, this is how we customize the logo. We have seen the trainings talking about something about the Volto add-ons. So Volto add-ons, something which is a bit like,
14:03
I would say a different component which we can use and then it can be anything. It can be block, it can be a widget, it can be control panel and we couple it with the main Volto application to a single config registry and then we can just deliver a whole website, deploy a whole website.
14:21
The small like a configuration of a, if we want to add a new block as an add-on then this code snippet. This is a custom widget, how we add it and it's also a Volto add-on. So we use it, we first add it and then we use it in the schema.
14:42
This is the Volto documentation. If you want to learn more about the Volto add-ons, how do we develop it, how do we deploy it? So we can, it's a nice documentation. Also the third one is, like we should have a design system which we can really focus on
15:00
and then that, we should have these components, all of the components that our website uses, we should import from a centralized design system otherwise if you use more different libraries then it could be a mess. So we have been, like it also helps large scale teams
15:20
to have a centralized design system and import things from that. We have at EA, we are building a design system and with my colleagues, I'm also involved in this. So it's also a design system which we started a bit like a year ago and it's now under active development. So it makes development for the front end easier
15:44
and will migrate all the EA websites to use the design system. The fourth one is the performance. Yeah, we use server-side rendering and bundle splitting and the lazy loading and they were like, we're using since quite a long time.
16:02
So like a little bit of a server-side rendering. So if you see the Cypress, if you create a simple test, if you request the route and if you inspect his body you see that the website has not even rendered because the hydration hasn't occurred but we have the HTML coming from the server.
16:23
So after that the hydration occurs and the client-side takes over. So the one, the observability is the last one. So when we deploy the website, we should make sure that our website runs good. We should continuously monitor the errors and for that, so for that we use,
16:45
at EA we use the Sentry and the other tools like lower ball. We use Sentry in EA to continuously monitor and logging the error system if you have it. And it really makes life easier to identify the errors in production.
17:02
It also shows this nice tracebacks in the errors and like what if you have it. Yep, thank you. Any questions?
17:28
Question, Volto Frontend have a large JavaScript bundle size. These results in poor performance in unreliable mobile networks. Any tips in optimized delivery of JS bundles
17:43
in the real world? Any tips to reduce the bundle size? Yeah, so we have the Webpack which usually cares of, which spits the bundle out of it. We can, if you want like every add-on you can alter the result configuration.
18:01
The result is just the Webpack centralized config. You can add your own plugin and you can, I mean alter the Webpack configuration in an add-on and you can split the bundles. And one more thing, if you have a big library then you can also lazy load it in a different bundle. If you think the library is big
18:22
and should not be included in a single bundle you can lazy load it and we have several helpers in Volto for it.