Problem
Well, start with the problem at hand. Several systems support several functionalities, whether they are applications or pages, and most of them independently.
But for lack of planning, this system becomes a single and complicated project, being difficult to install or update.
The proposal would then be to modulate it, making parallel development, easy, and effective, since a change in an independent module would not impact the update of the entire system.
This concept is already well defined, but I am clearly looking for how far this is possible, and if it's worth it.
structure
The images above describe well what we intend to do in the system.
We intend to divide the system into independent modules, but that can share some things with each other, such as dependencies, interface design and global states.
Possible solutions - Pros and Cons
Here begins my question in question.
At the end of the construction of this project, we should have a system that can be developed separately for each module.
some solutions
Micro Front-End - React
Monorepo - React
Well, we know that there are several ways to configure a react project and launch it, and here begins another challenge.
Another important point is the generated build, it is interesting to keep the react pattern, in which several .js and .css files will be generated in a build folder, making it easy to launch it into production.
All modules would be using the same language (javascript) and the same framework (react).
Well, what would be the best alternative given this project scope? I read several articles demonstrating how to implement monorepo or micro front-end, but most were simple or didn't show the entire process, how to build etc.
A simple demo containing the above idea would also be interesting
I would go with monorepo approach specifically: https://turbo.build/
With this, I can have multiple packages in same repo as well as web apps at the same place.
I would structure them like this:
apps
- mainApp - App with module federation
- module1 - app hosted at /app1
- module2 - app hosted at /app2
- module3 - app hosted at /app3
packages
- app-container
- app-requests
- app-translations
- app-logs
- app-tracking
- app-state-management
With this approach, you can add more packages quickly and can have common utilities shared across multiple web apps. You can add multiple packages as your needs grow and quickly use them across the different web apps quickly specifically configuration-related things like sentry/datadog.
Later on, you can separate the apps and packages into multiple repositories if they get bigger and publish them as packages separately.
Additionally, you can have one main app that implements module federation and can use other apps independently deployed at their respective URLs. You can read more about module federation here: https://webpack.js.org/concepts/module-federation/
Related
Until the release of TurboPack, using NextJS in this project can be tricky as webpack slows down with scalability.
The issue is that my project contains several components that are imported into the whole system, the system divided into pages (modules).
What strategies could I apply to have the least impact on:
Construction process, as atoms are less likely to change
Importation of these components by the client, because depending on how it is, the client will download all the atoms even the unused ones
And of course, the development process cannot be arduous, it must be simple to keep those atoms.
I'm using NextJS 13
This question already has answers here:
How to get Django and ReactJS to work together?
(8 answers)
Closed 1 year ago.
I am making a full stack website using react and django. I came across various ways to integrate them both. Having them both as two separate projects and interacting using API, or putting react in the django folder and calling the backend. Which method would be better and much easier? And can you also mention the pros and cons of each method.
Well, it's actually quite easy, you just have to wrap your head around which part of your project handles which concern.
The "project management" part of the question
Having them in the same repo
This is a good idea for deployment, as you won't have problems of synchronization between the 2 code-bases, however, with increasing number of developers it can potentially lead to management problems, as you're have branches based on both backend and frontend things.
So to summarize:
Easier to deploy, since it's a single code base
Could lead to potential problematic management with scaling the development team
Makes task that are "full-stack" easier to manage, as you have it in a single code-base
Not so easy to split if you're aiming to scale separate "frontend" and "backend" teams
Having them in different repos
In contrast, this makes it harder to deploy, but easier to separate the tasks. You have 2 separate projects to maintain, an "API" and a "front-end". Depending on the way you set this up, you can even serve your front-end project using a CDN, and this opens doors to some modern stacks, like serverless, or you can deploy on Vercel, which has a free plan. All-in-all this is usually a safer option for larger teams.
So to summarize:
A bit harder to deploy, manage staging
Easier task sub-splitting between the teams
The "engineering" part of the question
In regards to the engineering part, React has to be "transpiled", which means that the browsers don't know how to "interpret" it. That means you'll have to pick one of various bundlers, but I can suggest a few popular ones:
Webpack custom made config
Create React App (comes with webpack)
Parcel (0 config)
Snowpack ( I've heard great things about this one, since it's node_modules "free"
Once you have this, you'll have a way to get "production" ready compiled javascript/css assets which you need to serve to your user. Depending on what you went with on the "project management" side of things, you can either serve the assets with one-click solutions, or a CDN, or in fact, merge your front-end project with the backend, and build your assets, and serve them with Django itself.
The choice depends on what you want to achieve, but to summarize:
Serving with django - You'll only have a single server to handle everything, but that means if you plan your site to be globally available, you'll have think about the infrastructure
Serving with one-click solutions or CDNs, and a separate API - Pick this if you plan to have a fast loading site everywhere in the world, makes it a bit easier to scale
All-in-all this is kinda a complex topic, but if you're just making a startup or a small project for yourself to play with, I suggest you go with simply serving everything with Django, and keeping everything in a single codebase!
I'm looking for a solution for a bit of an odd situation. Let's take a quick look at the angular2-seed project so I can better explain: https://github.com/mgechev/angular2-seed/tree/master/src/client/app.
In that project, we have 3 isolated modules - about, home, shared. What I am looking for is a way to isolate development of these, so we're ultimately able to release each piece independently. For example, say Team A is working on the about section, and Team B is working on home. Work is complete for each, and we're ready to release, however we realize the about section is missing a critical piece of functionality, however we still want to release the change to the home section. What we're looking for is a way to achieve this.
Here are some solutions already explored, but I'm not really happy with:
Have completely different applications for home/about (in my eyes, this eliminates many of the benefits of a SPA).
Have each module (about, home, shared) roll up into it's own NPM package. When we go to deploy, we would have some way to orchestrate pulling in all the published NPM packages for these modules.
Orchestration:
Have each team build a component library (NPM) and pull those into a single Angular 2 application. That way, the teams can develop using microservices principles, but you can deploy a SPA monolith which reduces complexity.
Large component libraries should have multiple bundles and modules so you can be selective about what you pull in.
Communication between microservices:
If necessary, the component libraries can communicate over a back-end message bus.
If direct client-side integration is required between the component libraries, then you need a 3rd component library that about and home depends on, which contains a light-weight injectable message/event service. You can implement that service using RxJS Subjects.
A javascript meta-framework could work for you.
Here this interesting project
It takes inspiration from React component lifecycles by applying lifecycles to entire applications.
Some features:
Use multiple frameworks on the same page without refreshing the page
(React, AngularJS, Angular, Ember, or whatever you're using)
Write code using a new framework, without rewriting your existing app
Lazy load code for improved initial load time.
I hope it helps you to go in the right direction.
I am working on a fairly large webapp in Meteor. As advised my many experts, a good way to go for large apps is to split the different parts of the code in separate packages, like, e.g. Telescope. I designed everything with this objective in mind so I expect to be able to port everything to a package based "architecture".
Moreover, I plan to open source soon, so it should be also easier to maintain that way.
I have different types of users. Depending on it, I would like to build the app differently:
One type of user is using the browser based version of the app. This user will get everything since I don't know how to selectively send some parts of the UI/client code (and I assume I can not)
One type of mobile user will only have a subset of packages.
Another type of mobile user will have another subset of packages.
So I have a browser full version (delivered by server) and two mobile app versions.
My understanding of mobile app exports is that I can compile different versions of my client code by removing/adding some specific packages before compiling, since a mobile app from meteor is a packaged version of all client side related code in an app.
Is that correct? Am I overlooking something?
I have been looking into this for a couple of days and things are changing in the Meteor world with the upcoming v1.3.
Regarding my question, yes, it could have been a way to go after meteor v1 if I believe this article
However, one of Meteor dev "announced" that Meteor will eventually drop the package system in favour of npm. One of the good things is that npm allows lazy (i.e. conditionnal & role based) loading of the different npm assets.
I will then look into this possibility. The one thing I miss would be an article or a tutorial showing what are the best practices when splitting a meteor app into npm packages. I assume that some, if not most of the advises for package based architecture are still standing.
I'm studying a bit of ember and I like it so far. The problem I have with ember (and most frameworks I saw, both server and client side) is that almost all tutorials and guides are designed for small apps (as TodoMVC). I'm interested about how to handle huge administrative apps (like 30 or 40 pages, or more). That reason made me go for framework-less apps many times. What I saw is that you can use Yeoman or another tool to build a single js file and html. Most people focus in how to split the code in development and it's okay. I want to ask you how to divide the code that is downloaded at runtime. I think (maybe I'm outdated) that the users of administrative apps don't have to wait for the load of the whole app. They use 4 or 5 pages of the whole stack most of the time. I read briefly about require.js but ember doesn't advocate using it. What I need is a way of lazy load templates and javascript code like routers, controllers, etc.
How do you guys manage apps like those I mentioned?
There is a great blog post from #mixonic on this topic. It explains how you can use a before hook in the router to lazy-load scripts for one or more routes in your application. This technique can be used to lazy-load any application code including routes/controllers/models/templates or third party libraries.
http://madhatted.com/2013/6/29/lazy-loading-with-ember