I've been playing around with Yeoman and it's pretty great.
I'm wondering how people are integrating the resulting frontend app with backends?
Are you keeping them as separate code bases that potentially run on separate servers?
Are you stuffing the whole directory in a rails public folder and pointing the root route at index.html buried in there?
Up until now I've only ever used helpful gems to integrate backbone or ember into the rails asset pipeline. I could certainly move various files into the assets directory of a rails app but that kinda defeats the purpose of Yeoman.
So far I only used it to make and maintain the frontend app, using ajax to get all the information needed from the backend deployed as another project (web service).
Related
I recently joined a team with an existing React.js web project. We want to add a ASP.NET MVC backend to this application, but ideally, we want the option to complete the integration slowly without taking down the existing application for a full refactor.
My question is, what is the least invasive way to integrate this new backend, if our priority is to rewrite as little of the frontend as possible right off the bat?
I have seen a lot of information on using Babel to integrate the React.js frontend directly into the ASP.NET MVC file structure, but it might be ideal to keep them as separate projects for now. It does not matter that they compile and build together, we would be fine launching the backend and frontend separately starting out. Really, we would ideally just re-route traffic from our front end to our new backend without changing the front-end project at all.
What we have tried: We did get a ASP.NET MVC backend with a React.js frontend set up using Babel, but wanted to check to see if anybody here has done something similar before copying our entire file structure over.
I am developing a web application with an API written with Node and an Angular frontend. My current deployment pipeline watches source control for changes and then pushes everything to a build server, where it is built and then deployed into production. Currently, my Node application is set to serve the Angular frontend, which is unnecessary and needs changed. My question is, would it be a good idea to place the front and backend applications into different repos? That way, I can control the deployment of each on individually. My Node app uses a lot of C++ libraries that take some time to compile, and I don't want to have to compile them every time I make a change to the frontend. Is it a good idea to separate them?
To avoid re-compiling back-end libraries when you change your front-end code, you don't need to separate repos.
Some rule in your gulp/grunt/whatever config should suffice...
I have an existing webapp built on Laravel. I am moving to an Ionic build to create the native version.
How would you suggest I separate my views, and how do I call the routes? Has anyone any example.
Here is what I am about to do:
1. move all my views to the public folder
2. install Ionic in the public folder,
3. Using UI-route & Angular make $http calls to the backend.
Thanks for your input :-)
You can't simply do that.
If you have a "classic" Laravel app with blade templates, what you need to do is to expose an API from it.
Then you create an ionic app in a different directory (they are not related, so you don't have to mix them). You just need to develop your ionic app like any other ionic app. Then in your factories where you do the request to your API, you do something like:
$http.get('https://example.com/api/foo')
Where example.com is the domain of your Laravel application (You are going to need to activate CORS in it).
You just can't simply create an ionic app inside laravel, because that application will be built into an .apk to be installed on the phone and you can't add Laravel inside the package.
So the TL;DR is having your normal Laravel app where it lives, add it some public API so your ionic app can access it and then build an Ionic app from zero that will use that API.
It depends on you, but I prefer to keep the ionic project nested in /public, since I want a single-project app, the sources are clearly separated by being or not in the subfolder, but it helps your productivity, benefits are:
Single source control: Single source set for source version control (GIT, SVN, ...), so when I work I can do a single pull/checkout and push/checkin
Single app to deploy: Single domain, no cross-domain problems, single deploy via FTP is available, any standard php server can handle it with a single and standard account to handle
Coherent project without interdipendencies: I do not want to split logic dependencies of the same model between many projects, when I change something in backend or frontend that involve the other side, I want to have in the same project all the sources to update. It make not sense to have to go to a different project to adjust compatibility, it would be uselessy messy
I'm trying to host my first website. I've made it using angularjs, bootstrap and yeoman as a generator. However when I tried to upload it, I realized that the full size of everything in my folder (including the generated stuff by yeoman) was nearly 100mb.
What files do I actually need to host? Node is nearly 60mb and grunt isn't much smaller. Any advice would be greatly appreciated.
Assuming you have a web server like nginx or apache already on that server, you just need to upload the dist folder that is created when you run grunt build.
You don't need all that generator and node stuff just to host a simple test project.
What you actually need is a single HTML file, called index.html. Include Angular and bootstrap (you can omit this, too, if you can go without fancy styles) and create a file app.js which will hold your application logic.
http://angularjs.org shows this in a neat way on their landing page, just scroll down to 'The basics'
As static angularjs application will contain mainly HTML, CSS and JS files you can host your project on simple apache webserver. (Apache - http://httpd.apache.org/)
If you are making a dynamic angularjs application you will have webservices returning you JSON data. If you implement the restful webservices in Java (using Jersey) you can deploy you entire angularjs application with java webserivce implementation to tomcat web server. (Tomcat - http://tomcat.apache.org/)
Hope this helps!
Decided to answer this old question because its one of the few that show on google when searched.
You do not need to use Grunt anymore, I do not know if this was needed at the time of this question.
instead just do
ng build my-app
this would have saved me some hours.
link to current doc
I am currently working on a Java based Maven project that has a REST backend module and using angular JS as a frontend that uses the backend for data. The 2 modules are named "rest" and "web" accordingly and are deployed as 2 separate war files to a glassfish instance during development. The glassfish is on a different machine.
My problem is that this is kind of slow, especially when developing the angular based frontend. Fix a minor spelling mistake, package, redeploy. Not that slow but every character change or fiddling with angular is another 20-30 seconds lost.
One thing I tried is to directly load the files from the source directory into the browser with file:// tag. This is OK as long as it tries to call the REST backend which fails due to CORS (I don't remember the exact error message, it just doesn't work). This happens a lot so it's a no-go.
I'm open to every kind of solution to develop angular in a way that I could see my changes instantly instead of deploying it every time? Much like the guy does in the egghead videos.
I would recommend breaking your Angular JS application into its own separate project, this would be a new HTML5 project on Netbeans. That way you can focus on pure backend and frontend development in their respective projects and you do not have to manually separate the war files. This link will help you to get CORS working if you are defining your RESTFUL services with Jersey Access-Control-Allow-Origin in ajax call to jersey rest web services. Or you can just mock the data out in the front end project.