I'm about to start a pretty huge project.
This project is a website.
The backend will be made with Node
The frontend will be made mostly with Angular
Backend is going to be an API (which is cool with Angular) but also (later) for an Android app.
Frontend is going to be a fork of this repo : https://github.com/maxime1992/webTemplate and I want to be able to pull from upstream to keep the fork up to date.
I am wondering. How should I manage it?
Should I create only one repo, containing back and frontend with Git submodule or subtree.
Should I create two separated repos, one for the frontend, one for the backend and then use symlink to have them together? But if someone wants to run it on Windows ... Too bad.
I want this project to be open source on GitHub so I would like to have something clear and easy for everyone :)
Tell me how you would do it, what's good, what's wrong ... I'm really curious!
As indicated in the comments, Git submodules (or Git subtrees) are not the right solution for this. Use a dependency management tool for this, which will work cross-platform (Linux, Mac, Windows), and is the standard way of doing this.
Separating your backend and frontend into separate projects is a good idea, as it will allow you to manage projects independently and add functionality or additional client applications later without bloating your application.
Since you're already using Angular for the frontend, I suggest you take a look at Bower, which is the de-facto standard dependency management tool for frontend projects. It allows you to define a bower.json file to define your dependencies, e.g. Angular and other frontend libraries, allowing you to assemble your frontend project without having to download and store libraries manually.
In your backend project, you would then also add a bower.json file which declares your frontend project as a dependency by pointing to its Git location and branch. Bower will then take care of downloading your frontend project and adding it into your backend project.
Check out some of the popular Bower tutorials for more info on this...
You can use bower link to automatically create symlinks between your projects - this will work across operating systems as well.
Some other tools that you might want to check out:
Yeoman for scaffolding a base project. There are some nice generators for scaffolding Angular projects, including things like LESS/SASS and Bootstrap (https://github.com/yeoman/generator-angular)
Wiredep for automatically wiring your Bower dependencies into your index.html file.
Getting your initial project setup right will be important. You can start small and grow things to a more advanced configuration later.
Related
Struggling with collision of technical terms (most especially the term "plugin" which has about seven different meanings within the react development stack).
Short question:
Is there a way to pre-compile static webpack modules that can be installed separately from a main static react web application, while still sharing modules contained in the main web application? (The question as best I can formulate it using my relatively naïve react developer skills). I'd like the ability to plug in web user interface components supplied by 3rd party developers after the fact. i.e. installable runtime React UI components, not requiring react compilation at install time.
Details:
I have a static React web app that allows remote control of audio plugins (specifically LV2 audio plugins). It's a single-page static react app (that communicates via we sockets with the running application), hosted by a static C++ web server. Realtime and IOT agility requirements make a python hosted dynamic web server an runtime compilation an unattractive prospect (https://github.com/rerdavies/pipedal)
What I want to do is allow extension of the web UI using separate bundles provided by 3rd-party LV2 plugins. The ideal solution would be to allow static webpack bundles pre-compiled by the lv2 plaigns and placed in /usr/lib/lv2/<pluginname.lvw>/resource directories to be consumed by the web app at runtime. I'm using a custom C++ web server, so redirecting URLs into the /usr/lib/lv2/xx/resource directories is straightforward.
The main app would be distributed one apt package. Lv2 plugins would be compiled (potentially by 3rd party developers) against an "sdk package" provided by the main app build, after the main app was built, and then distributed in separate packages. Ideally, I'd like to pre-compile the ui code for the plugins to static webpack modules before their installers are built.
I more-or-less understand how I would do this if I were using raw CLI tools and configuration files (tsc, webpack, babel). But I can't help thinking I would be reinventing a wheel. (And I do have concerns that I'm going to incur serious version-dependency problems).
I would like to code-share the base modules (react, #mui controls, and a limited set of app-supplied components and interfaces).
I see the path through the various tools to make this happen, using my own custom build script, I think. I can get the typescript compiler to do code-splitting; I can probably figure out how to get the babel transpiler to do the right thing. And I think I understand how to write webpack configuration files that will process do sharing of modules from the main app. And a likely path to build and distribute an npm package to do the setup and build of LV2 plugin projects. And how to write supporting CMake build rules for building and installing such packages. &c. But I'm concerned that I'm going to go down a large rabbit hole trying to reinvent something that surely must exist already. And I can imagine seven thousand ways for this to go horribly wrong. :-P
So far, I have implemented the TypeScript compiler portion of the build procedure. And writing various bits to dynamicall intercept and service resource requests in the web server is trivial. But it has become painfully obvious that I also need to do babel and webpack build steps as well.
I haven't yet looked at the react-scripts package contents to see if I can steal code to build what I want there. Perhaps that's a viable path.
Is there a way to do this with off-the-shelf npm packages and off-the-shelf npm build procedures? I can find all kinds of bits to get me part way; but the integration of all the bits is rather daunting. Should I just do the deed, and start writing my own custom build scripts to make this happen?
I have a NX Monorepo with 2 react applications and a shared library between them:
-apps
-app1
-app2
-libs
-global files for both apps
I have them both deployed on AWS codepipeline with s3 bucket and they share one monorepo repository, but the main issue here is that whenever I push some changes to the repo, no matter if they are in the libs(shared) or the app itself, the pipeline rebuilds all of the applications I have, my expected results are if I change something in the libs for example to rebuild all projects, because it affects them, but if I do a change in app1, which doesn't affect app2, AWS to rebuild only app1.
I read a lot of posts and landed on Lambdas and Lerna js, but everything looks pretty complicated since I am new to AWS
this is an image I landed on, it shows that I need to use lamba functions to check which part of the repo is changed and determine which pipline to rebuild, I would be really glad if someone simpliefies things for me so I can find easier solution or if someone dealt with this problem to help me find a solution.
If you use codepipeline/codebuild with a self-created build server container image including nx you don't need that logic. In that scenario nx inside build server watches for changes and builds only needed changes. Obviously you have to use EFS etc. for persistence.
Questions: What is the correct / proper structure of Frontend and Backend together? How do I publish whole project after It's done? Will it just work if I copy it all to some host? (I know I have to modify DB paths and stuff, I'm worried about all the updating that composer does.. or am I understanding it all wrong)?
Short explanation of how I got here: I'm a student developing a Time management web application (Projects, Tasks..). I have knowledge of PHP (Slim), JS (JQuery, Angular), HTML, CSS (Bootstrap), SQL. My development flow was first creating a database and setting up an Apache server (Linux). After that I started coding by simply creating a folder, adding sub-folders for backend (DB operations..) and frontend (js, css, view, images...) when I needed them. All the includes were downloaded when I needed them (jquery, bootstrap etc.). I never used composer/ npm /bower.. Which brings me to this:
Current situation: I was about to upgrade form Slim 2 to Slim 3. In the last 6 hours of googling I've completely lost motivation and at the moment I feel like I have no idea what I'm doing. Almost every article/tutorial I read gives me different information: Composer? Bower? npm? Yo?... I feel like I'm doing it all wrong. I tried few of those seeds that create a clean project for you.. WHAT ARE ALL THOSE FILES. I even tried one that creates clean structure of Angular and Slim in one project. Needlessly to say I'm completely lost. I feel like I did all those 100 hours of coding while I should be studying for nothing, since i have no idea how to properly use it.
I'd really appreciate any tip, suggestion, links to stuff that'll help. I feel like all the knowledge of coding I have is just useless since I have no idea how to use it properly. Thank you
This is very simple to work with composer and npm for Slim3 and Angular2
both are different files and main folders
For Slim you will use composer to download all files in vendor folder
For Angular you will use npm to install all files in node_modules
folder
Even the required file is different composer.json for slim and package.json for Angular.
I use Slim with Angular 4 now inaa project and every thing is going smoothly
I don't know what kind of problems you faced, but I'm sure both can work together
I know that all these components exist, however I really am trying to figure out if someone has brought all these together.
Here is what I need:
JavaScript/NodeJS core application boilerplate/framework
With a website, HTML app (aka PhoneGap or even better Ionic), and ideally option to add something like a desktop app (like electron) client flexibility
All with possibility of different/specialized frontend code so all assets and HTML could be packaged into the app
Ideally kept in one GIT repo
With shared code amongst all UIs
Ability to use Angular 2 in all environments (or something similar)
Realtime? standardized data connection with data source (like meteor's DDP), I really dislike polling and I don't want to have to write my own data protocol
Have some kind of authentication capacity
Already exist in some way
What I have been eyeballing thus far is Ionic2 on top of Meteor, however it is remarkably difficult to find an actually working example of them playing together and I have not found any with separate codebases between the two interfaces.
To clarify, below is sort-of what I envision for a folder structure:
public/
common/
models/
business-logic/
server/
web/
desktop/
mobile/
And in that, all UIs and server can import from the common folder.
The end goal is to have something like Slack where they have 3 different ways of accessing the same data using the same rules but can really specialize in each interface type.
Does this exist?
I am really looking to have something that can be started with:
git clone http://github.com/a/bc
npm install
# do some other things that are documented
meteor run ios
Or am I not gonna have my cake and be able to eat it too?
I know I am shooting for the moon, but I know I can't be the first person looking to do this
For the backend I think that LoopBack may be a good bet if you want fast developement.
They have some examples for iOS, Android and Angular apps on their website:
You may get some ideas from their documentation or several example projects on GitHub.
LoopBack is currently backed by IBM.
What is the decision tree to know when to split a suite of related and/or cohesive applications into git repo's and/or branches? Should I keep each app in a repo? Or all app's & dependencies in a single repo? Or something in-between?
answer How should I organize multiple related applications using git? claims that a repository per project is appropriate, but does not give clues as to what a project would be.
And then there's the question of dev, test, integration test, and production checkouts when the git repo's are split. Answer how do you organize your programming work lists some branch/tag options, but ignores the multi-app details.
There's also the DB schema! incremental definition of the schema helps, but again, where would one keep this definition if the DB spans back-end and front-end app's?
Some examples I've been pondering:
a front-end web app and it's back-end CGI/DB: one repo or two?
a set of web back-ends that use features from other back-ends
a set of front-end app's that share CSS and jquery plug-ins
selenium scripts that test front-end features across dependent code - in the front-end app repo or the dependent code repo?
If I want to work on a single app, it's hard (well, tedious and error prone) to check out a directory of a repo, so I have to check out the entire git tree (or at least clone the whole tree), so that implies that git is not really built for keeping all the app's & dependencies in a single tree.
But if I want to keep each of the projects (app's, frameworks, dependencies, doc trees, CSS) in it's own repo, then I run into chasing my tail for dependency resolution, that is, I don't know which version of each app are compatible. I think git tags are a good way to go, if only I could move them to newer versions that maintain compatibility.
When app's split or merge -- as happens often with refactoring models down to baser models -- can i move the git history of just those files to another git? I don't see how to do this, so that leans towards a single repo for it all.
If I develop a new feature across app's, it would be nice for branches to represent features.
I think I want a repo of repo's -- does that exist?
This is about using a component approach: a component being a coherent set of files which have their own history (own set of branches, tags and merges).
It should include only what cannot be generated (although the db schema can sometime be added to the repo, as seen in "What is the right approach to deal with Rails db/schema.rb file in GIT?". You still can generate it though, as shown in "What is the preferred way to manage schema.rb in git?", to avoid needless conflicts)
A component can evolve without another one having to evolve. See "Structuring related components in git".
That is the main criteria which allows you to answer: "X and Y: one or two repos?".
You can split a repo into two later, but be aware that will change their history: other contributor will need to reset their own repo to that new history.
You can group those different components repos in one with submodules, as explained here (that is the "repo of repos", or, if you want to have only one repo, in subtree, as illustrated here.