I need to separate my Frontend and Backend into two different repos. Because one developer can't install rails and doesn't need it (we can make stub for API).
How can I do it in case of deployment? Do I need git submodule? How to use it (with GitHub and Ninefold)?
I found information about how to develop standalone frontend app (thanks I can use grunt) and how to use submodules, but I can't combine it. Please help! Does anyone have such experience?
Having your rails app provide a RESTful API is a good idea here. Your standalone front-end app can then interact with the API over HTTP(S).
If you want the front-end app within the rails app but need repository separation (i.e. don't want the front-end developer to access the code of the rails app), using a git submodule may work but probably needs some organisational thought.
This is what I'd do:
First clone your rails app from GitHub or Bitbucket (or git init one locally) and then configure a git submodule.
git clone git#github.com:pathto/myawesomerailsapp.git
cd myawesomerailsapp
git submodule add git#github.com:pathto/mystandalonejsapp.git app/assets/standalone
Now when you cat .gitmodules you'll notice there's a new submodule configured in your repo.
Commit and push your changes. Ninefold will detect the submodules and use them, but if you have any problems just get in touch.
Good luck!
Related
I just finished making an ember project (super simple nothing huge)
You can check it out <here>
but I am trying to deploy it to make it into a website on github pages and there is hardly any documentation out there and was wondering if I could get some help. Thank you
There are three strategies to do so these days:
Ember CLI Deploy is a famous deployment pipeline for Ember.js applications. The ember-cli-deploy-git plugin adds support for GitHub Pages as deployment target. There is an additional plugin ember-cli-deploy-git-ci, which adds support for deployments from a CI pipeline on top of that one.
The Ember addon ember-cli-github-pages adds a command to Ember CLI, which deploys the project to GitHub Pages. It's similar to the Ember CLI Deploy pipeline but working as a standalone solution.
You can deploy to GitHub Pages from GitHub actions. There are different Actions available in GitHub Marketplace to do so. The most famous one if comparing by stars is the GitHub Pages action. To use it you would need to build your Ember project as usual and set the publish_dir option of the action to ./dist. Ember CLI stores the build output by default in that folder.
It's up to you which approach you use. All of them are common in the ecosystem. Maybe some hints to decide:
If running the CI on GitHub actions, I would recommend to also us it for deployment.
If using Ember CLI Deploy in that project already for deployment to another environment, I would recommend to use it for deployments to GitHub Pages as well.
If not using a CI at all and just looking for a quick solution, I would go with ember-cli-github-pages as this is the simplest one.
If this is a playground project and you want to learn more about the common deployment process for Ember applications, I would go with Ember CLI Deploy.
I am developing an application which comprises a SPA front end and a Rest back-end.
To implement the Rest back-end I am using Node and Express.
Considering that both front-end and back-end are written in JavaScript (and TypeScript), I would like to share some code between these 2 parts (namely Interfaces and simple utils).
So basically my project is composed of three parts: Client, Server, Shared. Therefore I am inclined to have a project directory structure similar to this:
ProjecFolder
ClientFolder
.....
ServerFolder
.....
SharedFolder
.....
I am looking for suggestions on how best organize my project. I have done some research and I have found this interesting article which suggests to use a mechanism based on Gulp tasks that copy all files from SharedFolder into both ClientFolder and ServerFolder and then runs transpling.
I am wondering whether there can be an alternative approach or tools that perform what otherwise has to be configures as Gulp workflow.
My recommendation is to use a package manager tool. When you have dependencies, and the requirements of the server changed, you have to change the module. You don't want the SPA (frontend), to break, when you need to make changes to the server.
This is why package managers give you versions. Each module that depends on your shared code, can use a different version of it. You can use NPM for that. Build a module, publish it, and install it on your frontend and backend.
Many times, in production you split the frontend and backend. The frontend may exist in a file storage system (S3, Google Cloud Storage and similar), and the backend executed on your servers. Then it will be harder to use the same files on both systems.
I'm struggling how to integrate client-side modules like - just as an example - Apollo Client
into the qooxdoo-specific generate.py workflow so that they become available in the browser.
According to the installation notes:
To use this client in a web browser or mobile app, you'll need a build system capable of loading NPM packages on the client. Some common choices include Browserify, Webpack, and Meteor 1.3. [...]
Side note: I currently use Babel 6 to recursively transpile all my sources from a separate folder source.es6/ into the "official" source/ folder, which is then watched and processed by generate.py. Is it possible to use this somehow as a solution to my question?
OTOH, I would love to see at least some kind of integration with Webpack, Browserify or SystemJS.
I suggest you do the following. First, create a loadable package(s) from the Apollo Client and its dependencies, e.g. using Webpack. Then make sure these package(s) are loaded in your web page before you load your qooxdoo app. Then the Apollo API is available to your qooxdoo code.
If you choose to deploy the Apollo packages with <script> tags you can let generate.py do that by using the add-script config key.
I suggest you place the output of the Webpack run in your qooxdoo project's resource path and add #asset hints for those files in your main qooxdoo class. This will make sure they are copied into the build version of your app, and you can use the relative URI to these files, either in your index.html directly or in the add-script config settings.
I don't think your transpiling with Babel6 will help here. The Apollo code is already consumable and you woudn't want to disect it and make it part of your qooxdoo (es6) source tree, let alone its dependencies. I would rather treat it as a shrink-wrapped JS library as I described that is added like a resource.
I'm trying to work out the correct way to embed an AngularJS application into another web page (served by another app). I have two apps, running on different servers:
App 1 - PHP app
App 2 - AngularJS app (calendar widget of sorts)
The PHP app is the primary app, into which I want to embed the calendar, which is served from a remote server. I have full access to both servers, and to both apps. The idea is that I want to be able to re-use the Angular app elsewhere, so it needs to be as loosely coupled as possible to the PHP app, preferably embedded in a single line of code.
I am currently using a HTML5 tag, which seems to work well, but I was wondering if there's anything wrong with this approach, or if there's a better means of doing what I'm after.
I should mention that I'm happy to use a HTML5-only solution, I'm no worried about backwards compatibility with older browsers.
No iFrame solutions, unless there's a REALLY valid solution. My ultimate goal is to head towards a microservice-style architecture.
Thanks in advance for your help.
I generally manage all of my client-side dependencies with Bower but you could use any package manager.
This is how I would do it with Bower, which just uses Git to pull down your dependencies. This solution would require you to know how to use Git.
Install Bower—see above link.
Then, create a file called bower.json at the root of your project that points to the Git repository of your project:
{
"name": "my-php-app",
"version": "0.0.0",
"dependencies": {
"my-angular-app": "git#bitbucket.org:MY_BITBUCKET_ACCOUNT/my-angular-app.git#master"
}
}
Then you can run the following command in the root of your PHP project:
bower install
This will create a directory called bower_components at the root. You can configure the default directory.
Your application should be self-contained there. You can import it and all of its dependencies with PHP on the required page.
I am using Yeoman 1.0 beta and not interested in the express-stack branch. What, then, is the recommended/best way to use Yeoman to scaffold an Angular project within Express?
I tried running yo angular --minsafe in the root directory of the Express project (where app.js and package.json are), but Yeoman was trying to override package.json, and the Angular files didn't go into the public subdirectory properly. Also I am not sure if I can just go manually moving the Angular files around without breaking Bower and Grunt functionalities.
Would be great to have some advice, thanks!
This project seems to cover all of the requirements (and even has optional support for MongoDB): https://github.com/DaftMonk/generator-angular-fullstack
I've just tried it locally and it works:
npm install -g generator-angular-fullstack
yo angular-fullstack [appname]
See the GitHub page for more info.
If you install Angular first through Bower, then add Express to package.json and run npm install - you'll have an Express server fire-up the /dist directory. (Edit app.js to route to /dist and let angular handle routing)
See this SO question for more information: Yeoman inside ExpressJS
This is a comparison of alternatives for starting an AngularJS app. Several of them involve Express too.
http://dancancro.com/comparison-of-angularjs-application-starters/
After reading MANY blogs and answers, I managed to get it all working...
Check out this repo: https://github.com/malixsys/malix-yae
When changes are made to html/server or lib, the server is restarted and the page should refresh
When changes are made to HTML or JS files under html/client, the server is not restarted but the page should refresh
When changes are made to CSS files under html/client, the new stylesheet should be injected directly without refreshing