I've got a VS2013 solution with a mix of NodeJS (using TypeScript) and C# class library projects (they're bound together by EdgeJS). Where the NodeJS projects are concerned, one can be considered a library (for a RabbitMQ bus implementation), two are applications which are meant to be hosted as part of a fourth project with both using the bus.
So, one project (host) which will depend on three projects (bus, app1 and app2) (it starts the bus, and passes it to app1 and app2).
Of course, I could just lump all these projects together and be done with it - but that's a horrible idea.
How do I package these projects up for proper reuse and referencing (like assemblies in traditional .NET)?
Is that best done with NPM? If so, does VS provide anything in this area? If not, then what?
Note that, aside from the Bus project, I'm not looking to release these publicly - I'm not sure if that changes anything.
In general, if something can be bundled together as an independent library, then it's best to consider this a Node package and thus, refactor that logic out to it's own project. It sounds like you've already done this to some extent, separating out your bus, app1, and app2 projects. I would recommend they each have their own Git repositories if they are separate packages.
Here's some documentation to get you started with Node packages:
https://www.npmjs.org/doc/misc/npm-developers.html
The host project, if it's not something you would package but instead deploy, probably does not need to be bundled as a Node package. I would instead just consider this something that would be pulled down from Git and started on some server machine.
With all that said, your last line is important:
I'm not looking to release these publicly
GitHub does have private repositories, but as of now npmjs.org does not have private repositories. There are options to create your own private repository (Sinopia and Kappa offer different ways of accomplishing this), but if you don't want this code available for everyone do not deploy it do npmjs.org. You can still package it up in the way I've outlined it above, just not deploy it as of yet.
Related
Is there any standard/conventional way (package/library, pattern, etc.) to serve the latest version of some static files from a given git repository in Node.js?
My idea so far is to clone the repository at npm start and take the files that I need from there, and to provide a webhook to be called when the repository receives a commit, to then pull the changes so that the files get updated even when the app is running.
This seems like it could work, but I do not want to reinvent the wheel, if it already exists. If there is a method that is already relatively well known, a conventional pattern or a package that already does this, it would be wise to use it and not bother with implementing the details, fixing security vulnerabilities and keeping it up to date.
Also, while we are on it, are there reasons why I should not do this in the first place?
Edit:
I should probably give an explanation on why I would want to do this.
I basically have a web app (nothing too complex, a few routes here and there), let's call it example.com, and a few "self contained sites" (i.e. collections of static files that for all intents and purposes could live independently of the main website and each other).
I could put them each on their sub-domain, but that would probably mean using more app instances and time for just serving some static files, so I want to serve these "sub-websites" on their own paths on that app, like example.com/sub-site1, example.com/sub-site2, etc., from the same app instance as the main example.com, as to not incur higher hosting cost.
I could also modify those static websites to wrap them in Node.js packages and install the packages in the main app, but I want to keep them clean, simple, static files, agnostic of the platform they are being served from.
That leaves me with the option of moving a bunch of files to the main app, but I do not want to manually restart the app each time any one of those sites gets updated, or even worse, manually update the repository of the main app with the new versions of the static files.
Is there any standard/conventional way (package/library, pattern, etc.) to serve the latest version of some static files from a given git repository in Node.js?
There is no standard for this kind of task. The best way is to use the official Github SDK since there is a getContent method for this purpose.
Also, while we are on it, are there reasons why I should not do this in the first place?
A Github repository can be deleted, but an npm package cannot (there is a unpublish policy for this reason).
I don't know your use cases, but those files are critical for your application?
If so, it is risky to depends like this on an ephemeral repository: you could just fork and keep the fork up-to-date with a Github action
I am working on a project that has a few different code-bases (mostly Meteor), but they all use some of the same API code (schemas, publications and methods).
It doesn't seem very intuitive to have one repository and use sub-trees/sub-modules in my case. Maybe I'm wrong and somebody could help clear it up.
An example structure of my project:
project-landing-page (meteor app for collecting leads and offering basic account management)
project-app (an angular/ionic/cordova/meteor app that is distributed via the app store)
project-worker (a set of cron-like scripts that are executed in the background to manage the data in the mongo instance)
They all share the same schemas, and the two meteor apps use the same methods and publications. It seems a bit cluttered to have one repo for all of this code. Making a branch for the app would also branch the code for the worker scripts. That just seems messy.
Would it be okay to have another repo called "project-apis", that provides the shared code an could be cloned into the other projects? What are the drawbacks? Other than having to run git pull when the "project-apis" repo is updated, I can't really see any.
Would any git-wizards be able to chime in?
Thanks!
How can I share components across multiple react projects without having to publish them on a public package manager like NPM?
Option 1: You can use npm and use private packages so they're not external facing. There are also artifactories and scoped packages that usually represent company-wide projects that can be public or private. See https://docs.npmjs.com/private-modules/intro and https://docs.npmjs.com/misc/scope.
Option 2: Essentially, you can develop projects with a flattened structure. You can then import various projects and/or components into other projects or folders. This is entirely dependent on your codebase and configuration. With this model though, a lot of times publishing to npm comes fairly naturally since each folder may be its own project with its own package.json.
Updated:
Option 3: Bit focuses on the composability of components from everything from the little things like a button to the actual view and app itself—each target is its own package. Overall, it's an opinionated, yet customizable framework that can enable quicker development, managed dependencies, and organized code.
Option 4: RushJS is a monorepo manager built by Microsoft that allows for flexibility of different kinds of apps and services utilizing pnpm underneath (as opposed to yarn and npm), which alleviates problems that stem from dependency issues.
Check out Bit:
Bit is an open-source cli tool for collaborating on isolated components across projects and repositories. Use Bit to distribute discrete components from a design library or a project into a standalone reusable package and utilize it across applications.
You could also upload them to a private git repo such a Github and then pull them in from there.
Ryanve has a nice example over here: https://stackoverflow.com/a/28729646/1592783
You could create a repo of shared components and then have your Node.js start script call a shell script to do a git pull from that repo and the move the shared components from that directory to your project's directory. That way, every time you call run 'npm start' you will have the latest version of the shared components loaded into your project
I would like to know what is the best approach in create several deploys from a big code base. The idea is to divide the big API into microservices (each one in it's own server/vm),
The first idea: I could simply create a folder with only the available routes for that microservice, but still using the "common" codebase...
I currently end up with this, and it's a running API in production (with staging environment in heroku with their pipeline):
and I was thinking that I could have something like:
can anyone point me to a good reference on ... where to start? how can I push multiple version of the same base code to a server?
for more detail on the used technologies, I'm using:
mocha and chai for tests
sequelize for mariaDb modeling and access
restify for server engine
When you divide the API into microservices, you have few options:
Make completely separate repos for all of them with some code duplication
Make completely separate repos but sharing common code as Node modules
Make one repo with multiple microservices, each as its own Node module
Make one repo with one big codebase and build multiple modules with needed parts from that
I'm sure you can do it in even more ways
Having a mismatch of the number of Node modules and code repos will cause some troubles but it may have some benefits in certain cases.
Having a 1-to-1 mapping of repos and modules will be easier to work with with some cases, like the ability to add private GitHub repos directy to dependencies in package.json.
If you want to factor out some common functionality then you can do it in several ways:
The npm supports organizations, scoped packages, private modules and private scoped packages with restricted access.
You can host a private npm registry
You can host a module on GitHub or GitLab or any other git server
For more info see:
Node.js: How to create paid node modules?
There are some nice frameworks that can help you with splitting your code base into microservices, like Seneca:
http://senecajs.org/
Or to a certain extent with Serverless if you're using AWS Lambda, Microsoft Azure, IBM OpenWhisk or Google Cloud Platform:
https://serverless.com/
In order to present a brand new way of developing a web application, our team decided to create an Angular 2 web application that will be integrated within an already existing Maven Project in Eclipse Mars which DOES NOT use NodeJS nor Angular.
We are currently using the frontend-maven-plugin belonging to com.github.eirslet and managed to download and install both node.exe and npm.
Now, here is the deal: our web application has its own package.json file with all the configuration required to run properly, BUT we would like to be able to differentiate between the web applications, as each one of them belongs to a different working directory (i.e. com.webapp.app01, com.webapp.app02, ...).
As the plugin does not let the user use the npm install command on different directories, we were wondering about how we could reach this goal... maybe using a general package.json, but generating all .js and dependency files in each project directories.
Would that be something even possible?
Could you give us some help?
Thank you.
Cheers!
What I would suggest is to have a multi-module maven project, with a common parent, and children, that would give you this kind of architecture:
parent-project
|-child-project1 (java project)
|-child-project2 (webapp1)
|-child-project3 (webapp2)
|....
|-child-projectn (webapp n-1)
This way you can have for each web-app the frontend plugin available. And you can handle the flow of the build from the parent project (for instance if webapp2 needs to be built before webapp1, you can orchestrate it from the parent)
We decided to generate all the libraries locally and upload them to SVN, due to the fact that the already existing structure cannot be changed and the maven plugin is too much limited for our purpose.
Thank you for your replies, though. :-)