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
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
We have an large application spread across multiple teams, built with Java Server Pages. The goal is to migrate to Angular. A monolithic migration/launch was deemed not practical, so a gradual migration is preferred.
The idea is to use a Webpack 5 Module Federation app shell to load Angular micro frontend remotes into the existing JSP app. The question is whether to load the remotes as Angular apps or Web Components. The thought is that Web Components might allow them to embed a reusable microfrontend fragment into the JSPs in cases where they can't migrate an entire page at once, or they have components that will exist in both the unmigrated JSPs and the new Angular pages.
After the migration, they'll either keep the micro frontend architecture if it's justified, or abandon it and merge the remotes into one Angular app.
Another alternative might be lazy loaded modules rather than opening the pandora's box of micro frontend architecture. Just informally split the app up into lazy loaded modules per team. Downside here is possibly more teams stepping on each others toes in the repository, but that's no different than how they've been operating. Their concern about lazy loading modules is they don't think they'll be able to do something like this:
<!-- my ancient JSP site. LOL page load with every click -->
<JSP-header></JSP-header>
<myAngularComponent></myAngularComponent>
<script type="text/javascript" src="https://lawlcats.com/myAngularComponent.js"></script>
<JSP-footer></JSP-footer>
All in all, the proposed solution is incredibly complex. These teams are brand new to Angular and are already considering combining different frameworks within a micro frontend architecture, AND implementing web components. Sounds like a huge lift to me. I'm also unsure if they've considered how they'll manage the repository across teams.
Does anyone see room for improvement or flaws in this plan? I'd love suggestions for the micro frontend remotes being Angular vs Web Components, vs abandoning micro frontends altogether in favor of lazy loaded modules.
Well, it would be good if your team first fully grasped what are the implications of MFEs or WebComponents as tools.
Micro Frontends are self-contained, stateful, full-fledged, and fully black-box applications. Maybe it would help your team to think about them as iframes.
You stick a MFE app somewhere on your page, and that is it. It does its own thing. The host app just hosts all the MFE apps on all the different http ports, but it doesn't know anything about what's going on inside of them.
In the simplest classic example, there is no communication between the host and the apps, and the apps also never ever talk to each other. AFAIR, if you wanted them to communicate, it's theoretically possible to do that via http (since they do actually live on specific ports), or wild shenanigans like utilizing LocalStorage. But it's generally not easy.
WebComponents, on the other hand, are just raw components that do one specific thing. They are also black boxes, but usually super tiny and thin. You can think of them as something like input.
An input knows how it should be styled, it knows which raw browser Web APIs it should talk to, it knows that it should render text in response to the user typing on their keyboard, and how to expose a couple values and events to the external world. But ultimately, an input in itself is pretty dumb and can hardly be called an "application". It's just a small building block of the actual modern JS app.
inputs also don't talk to each other - why would they - but they expose clear, native html APIs for input and output, so the host app can very easily talk to them and make use of them. The host is still responsible for actually knowing how to do that though.
As for your use case, your options depend on your team's technical and business needs.
MFE Federation is a pretty strictly defined type of architecture. It might work in your use case, but you'll need to consider that trying to organize any kind of communication between these separate apps later on is asking for trouble.
On the other hand, if you really want to just have a bunch of modern JS components that you could stick anywhere in your existing JSP code, then WebComponents might be your best bet. IIRC, Angular components can be built and used as WebComponents like in your example, so it could be viable to write them in Angular (and then possibly migrate the entire app to an actual Angular SPA sometime later). The problem is that these components won't do anything by themselves, they still need the host page to actually use them.
It might also viable to write just one application with a bunch of lazy-loaded modules - which the standard straightforward case in modern Angular - and let it live under some specific routes. You would then just start rewriting pages in Angular one by one. Nobody likes that, but sometimes it's just what has to be done. As an upside, in that case at least you would have an actual modern Angular app as the host for all the JS components, instead of whatever JSP thing you currently have.
In theory you can mix-and-match approaches 2. and 3., with some pages only partially using the new shiny WebComponents, and some pages fully rewritten. It's probably what will have to eventually happen, but I'd try to initially stick to just 2 or just 3, to make the first steps of the migration simpler for your inexperienced devs.
Whether you choose Webpack MFE Federation, JS/Angular WebComponents, or a simple Angular SPA, I would strongly recommend looking into NX, which is a very powerful, framework-agnostic JS monorepo toolset. Among other features, it should help you solve the problem of managing the code between teams.
With NX, you can add arbitrary tags to all of your modules, and make the linter track and ban the dependencies between specific tags. As a simple example, your could say that modules tagged team-a cannot be used by team-b or team-c, so that Team A can safely do whatever they want in them without breaking anything that other teams actively use.
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 working on the first production release of a large site developed in PHP (Phalcon), MySQL & JQuery. It's not API based although there will be an API available for some things. The slightly dated stack is due to the fact that the project was first prototyped years ago and for reasons I won't bore you with, it's taken years to get to the production development stage.
I realise that hard page reloads are so last year, but they also make sense in an application of this scale when navigating to a different section that serves a different purpose. As it works at the moment, once you get to a section, it pretty much behaves like a single page app using hashed URLs and ajax to change the content in one or more containers etc. especially where SEO is not an issue. This is all currently done with JQuery which is starting to get a bit messy and unmaintainable. There's also features such as notifications in the nav bar etc that appear on every page on the site, again updated and displayed via ajax.
My expertise is in PHP. The same can not be said for Javascript! But it's clear that JQuery alone is not enough. I need a JS framework to handle templating/binding, local routing to a reasonable depth and http etc. with an MV..? structure to better organise the JS side of things and keep it maintainable. I greatly disliked Angular 1 and quit learning it as soon as I found out that Angular 2 was about to come along with major breaking changes. I tried Angular 2 beta and although better, it just doesn't float my boat. I had previously stumbled upon Aurelia alpha and although I didn't have a chance to play with it, watching the vids and reading about it, it seemed like a very nice bit of gear - nice syntax, designed for the present and the future and so on. Now at version 1 beta there's more documentation and resources available to learn it, and I feel fairly comfortable jumping aboard early and using it in this project.
I'm pretty much aware of what Aurelia can do, and I have a lot to learn. However, my big stumbling block at the moment is figuring out how to structure it and incorporate it into this project.
Integration
Each section of the site will need different Aurelia apps
Multiple Aurelia apps may be needed per page
Some Aurelia apps will be required on all pages
I found an article by Patrick Walters which seemed to explain how this could be done by naming the app when you call it on the element;
<body aurelia-app="main" start="app">
Then setting up a shared main.js with;
aurelia.start().then(a => {
let start = a.host.attributes.start.value;
a.setRoot(start);
});
That seemed to make sense so I tried it, but placing the call in a div instead of the body. That doesn't work as host can not be resolved to anything (my IDE told me that before I even ran it). We don't need hostname/port info here, so I presume the author means to replace host with the element? But how exactly?
Any further advice on integration like this would be much appreciated.
I have seen answers to similar questions on SO, but they do not seem to reuse main.js but duplicate it instead which doesn't seem right.
Structure
I played around with moving files with src to subdirectories to split things up into some clear structure. The only way I could get that to work was to add a named path for each in the config e.g. "welcome*": "dist/welcome/welcome*",. Is that the best/only way?
I don't think there is a right answer for your question. Only you are capable to decide which strategy fits better in your situation. As far as I can see, you can achieve this strategy with Aurelia. However, I'm not sure about the reusage of main.js.
You can load an aurelia app inside an specific tag using:
aurelia.start().then(() => aurelia.setRoot('my-root', document.getElementById('some-element'));
If you want to load more than one app in the same page, you'd need 2 main.js files. This thread Multiple Aurelia apps on one page has a very useful example of two apps in the same page.
In my understanding, apps that share the same page should have one project structure, it means only one config.js, src folder, dist folder, etc. Apps that do not share the same page should have a different project structure, with a different config.js, src folder, dist folder (a different Aurelia version if necessary). That guarantees the independence of one app to another, preventing breaking changes.
Of course, that is only my opinion. You can wait for the aurelia guys for further instructions, they are always around.
Hope this helps!
I have a huge client-side web application written in JavascriptMCV framework ~50 views, around 500.000 javascript code lines. Everything is built in JavascirptMVC formation using separate files for Controllers, Models and Views for each view = web page. The time has come to migrate to one of the modern javascript frameworks - I'm thinking about Angular and I'm starting to make an initial research about time estimations and human resources needed.
Are there some known techniques for doing that? If someone can point me to some article or knowledge base it would be very helpful.
I'm not sure if there are tools or special techniques to do this, but you could create an angular app around your current app.
You create an angular app from scratch, with a shared 'main' view (could be a new html page) which then uses ng-view (with angular-route) to load all your current HTML pages as partials. That way a lot of the page-linking can remain intact.. I do think that from that point, a lot of refactoring is required to make it an actual angular app.. Which raises the question, on what grounds do you think it's beneficial to migrate to a different framework when the old one is still working fine?
I currently have a web app written in rails3. I want to write a backbone-based js app that will consume the rails3 services; while there are alot of examples of backbone with rails, I would prefer to build it in a different project. This project would be pure html+css+js, wich would then point to the other proj's services.
What are the advantages or roadblocks of this approach?
Are there any other approaches?
I've noticed that most of the rails3-backbone projs on github do alot of the magic behind the scenes (ex: precompiling handlebar assets, auto-including js files), which makes it more difficult to understand how all the pieces work together. Also, if I want to package an app using phonegap/trigger.io/etc, wouldn't this be more difficult?
When it comes to writing Backbone application, it actually makes a lot of sense to develop it solely on its own. In other words, develop it, as you said, as a pure html+css+js application.
There are very good reasons to do so:
Deployment
Consider when you are deploying your application. At some point you will surely want to deploy some modular component of your application. This maybe the backend services which are responsible for serving json to your clients, or it could be a tweak on the UI. Whichever it may be, it is best if you are able to deploy each of them independently.
Modularity
It may sound attractive to be able to use some rails magic behind the scenes to help develop your UI. However, consider the modularity of your project.
IMO, Backbone (or any AJAX application) is beautiful. And the beauty comes from the very fact that the UI code really has nothing to do with the implementation of your backend. It could talk to a PHP/JAVA/RAILS/PYTHON/YOU-NAME-IT server, and it still wouldn't matter. That is, if you're implementing a RESTFUL server. In fact, the UI code could rest on an NGINX server that serves nothing but static content, and it would still run perfectly fine. This is actually what you want. Your UI code should at no point (during development or production) be aware of your backend's framework or whatever tools your backend supports. It would be a crime to introduce unnecessary dependencies into your Backbone project.
Imagine one day when you see fit to migrate to a different architecture which isn't Rails. It would be a nightmare if there are any dependencies at all. Much rather have a UI that is totally independent of your backend implementation.
Packaging
You mentioned you're going to use PhoneGap to package your application. This is probably the biggest reason why your project should be independent. You will not have the luxury of loading your js from your servers when you're say, submitting your app to Apple, if you ever plan to do that. All scripts must be packaged into the App which must be standalone.
Last but not least, to answer your question about suggestions for 'other approaches'. That is quite vague, so I'm not sure if this suggestion would help, but I wanted to point you to some resources that would help organize your Backbone projects, and make your life easier.
Backbone with RequireJS
I would argue that this is the most wonderful way to work with Backbone. RequireJS let's you specify your dependencies in your js files much like you would import in compiled languages, which helps a lot when it comes to organizing your Backbone project, and breaking the code down into smaller modules. The optimization tool that requireJS provides also let's you compress all of your javascript file into a single file. I believe that will come in handy if you want to package your project in PhoneGap.
Underscore
You mentioned using HandleBar. However, I recommend that you look into underscore's templating engine which is inspired by RoR's templates. And assuming that you're quite comfortable using Rails, the underscore templating engine might just be what you're looking for.