Oh, yes, they should match nicely. Although I have never dared to explore microfrontends to such extent. I guess I would like to see how micro services are working for the back-end systems in the long run first.
In the article I made a Create React App 4's app (based on webpack 4) to import a custom built module (using webpack 5) without issues. It's hardly suprising as in the end it was the webpack 4 that created a single bundle. Nevertheless it feels magical how each piece of the puzzle fit nicely and allowed for hot reloading a separate package. That's what I call sharing code seamlessly.
Yes, this feels truly seamless. However, I can imagine that monorepo might bring troubles with CI/CD when there are multiple artifacts produced for each app 🤔
That;s true. Although with some planning it doesn't have to take long and produce large Docker image diffs.
The biggest offender is node_modules for each app. Not only it takes long to npm install each of the apps but they also contribute hugely into an image size if not dealt carefully.
Install dependencies for each of the apps by copying just the package.json for each of the app and running their npm install.
Then COPY . . the rest of the files (with node_modules in .dockerignore).
Then build each of the app.
Each consecutive build starts from the step 2 which just copies the source files (not node_modules) and runs the npm build for each of the apps. And that's 10 times faster than installing the dependencies.
You can optimise further and instead of copying all apps together you can order them by their frequence of commits. Placing the most active one as the last step to copy source files and then build.
Yes, I suppose you're talking about docker layers and writing docker files in the way to reuse as much as possible to not trigger unnecessary operations while building the images.
I was thinking more about multiple teams (so many people) contributing to two apps and queueing builds/deploys many, many times.
Nevertheless, it might be that I'm creating imaginary issues that will never happen :-D
Multiple teams can create as many PRs to the monorepo as they want and each commit within the PRs will trigger a new build in a CI. It's not a problem given that builds are so quick thanks to the optimised Dockerfile.
Most of the time each team will update just their app leaving a shared UI code unchanged.
A deployment would only be a problem if the shared code had been modified. Then every app in the monorepo would have to be tested for regressions by a QA team.
But if a newly merged PR contains only code for a single app then it's perfectly safe to deploy it. For only the modified app will create a new CSS/JavaScript bundle.
I am assuming all apps would sit n a single Docker image running from a single nginx cotainer, i.e. example.com/app1example/app2. It's be possible though to make a separate build of a Docker image for each of the apps and run them in independent containers.
A risk of regression would still be present in this scenario too as updating the shared code alters all artifacts. But that's the trade off of using a shared code/DRY principle in the first place.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oh, yes, they should match nicely. Although I have never dared to explore microfrontends to such extent. I guess I would like to see how micro services are working for the back-end systems in the long run first.
In the article I made a Create React App 4's app (based on webpack 4) to import a custom built module (using webpack 5) without issues. It's hardly suprising as in the end it was the webpack 4 that created a single bundle. Nevertheless it feels magical how each piece of the puzzle fit nicely and allowed for hot reloading a separate package. That's what I call sharing code seamlessly.
Yes, this feels truly seamless. However, I can imagine that monorepo might bring troubles with CI/CD when there are multiple artifacts produced for each app 🤔
That;s true. Although with some planning it doesn't have to take long and produce large Docker image diffs.
The biggest offender is
node_modulesfor each app. Not only it takes long tonpm installeach of the apps but they also contribute hugely into an image size if not dealt carefully.package.jsonfor each of the app and running theirnpm install.COPY . .the rest of the files (withnode_modulesin.dockerignore).Each consecutive build starts from the step 2 which just copies the source files (not
node_modules)and runs thenpm buildfor each of the apps. And that's 10 times faster than installing the dependencies.You can optimise further and instead of copying all apps together you can order them by their frequence of commits. Placing the most active one as the last step to copy source files and then build.
Yes, I suppose you're talking about docker layers and writing docker files in the way to reuse as much as possible to not trigger unnecessary operations while building the images.
I was thinking more about multiple teams (so many people) contributing to two apps and queueing builds/deploys many, many times.
Nevertheless, it might be that I'm creating imaginary issues that will never happen :-D
Multiple teams can create as many PRs to the monorepo as they want and each commit within the PRs will trigger a new build in a CI. It's not a problem given that builds are so quick thanks to the optimised Dockerfile.
Most of the time each team will update just their app leaving a shared UI code unchanged.
A deployment would only be a problem if the shared code had been modified. Then every app in the monorepo would have to be tested for regressions by a QA team.
But if a newly merged PR contains only code for a single app then it's perfectly safe to deploy it. For only the modified app will create a new CSS/JavaScript bundle.
I am assuming all apps would sit n a single Docker image running from a single nginx cotainer, i.e. example.com/app1 example/app2. It's be possible though to make a separate build of a Docker image for each of the apps and run them in independent containers.
A risk of regression would still be present in this scenario too as updating the shared code alters all artifacts. But that's the trade off of using a shared code/DRY principle in the first place.