Objective:
Use a monorepo structure, in which I can share domain models and generic implementations (using a provider pattern) across the different Bounded Contexts
Ability to deploy each bounded context or client application independently of the others (thus all of this in a monolith under one src directory is not acceptable.
Background: Typical tech stacks for me is Angular + .Net Core. I am starting to move away from Angular and also exploring the code sharing benefits if I do my API development with Nestjs.
I am trying to figure out the best way to set up shared code between the client and API and running into some issues.
I have the following directory structure. I would like to figure out the best way to shared the models that are in the domain/models/comestibles in the api/comestibles and in the web application. I am ok with putting all of the shared code in a packages folder as well (was looking at Lerna)
I can easily point the code to the directory from the api/comestibles, but that is making the dist folder structure undesirable and also messing up things (like Swagger). I also had the change the outDir in the tsconfig.json from
"outDir": "./dist"
to
"outDir": "./dist/api/comestibles/src"
This broke other things in the application though as the directory structure is really altered.
I looked at setting up Bit and I have tracked some files, but I do not see any packages created for those files. Perhaps I am using it incorrectly though. I was also looking at Lerna for this. Given this is the first time I have done a full-stack application via scripting, I am unfamiliar with the best architecture for this solution.
Nx.dev plug-in solved my problem.
https://github.com/ZachJW34/nx-plus/tree/master/libs/vue
Related
Often I have code reused by multiple Netlify functions in the same project.
I know that anything within my /functions directory will become a function so I don't want to nest directories there. I could include it in /src, but if feels odd to comingle source with my single-page app (SPA) since they have different dependencies.
Is there a good convention for where to put this code? I can't seem to find any answer to this in any of Netlify's documentation.
Is it possible to have MVC in sub folders (modules) when using node.js express framework?
Today I have this structure of my project:
Controllers
Blog/*
Poll/*
And many more
Models
Blog/*
Poll/*
And many more
View
Blog/*
Poll/*
And many more
Routes
Blog
Poll
And many more
Should it be possible to have this structure in a module way instead?:
Blog
Controllers/*
Models/*
View/*
routes.js
Poll
Controllers/*
Models/*
View/*
routes.js
And more modules
When I develop I feel I mostly work with one part of the project at the time. When I the current structure its a lot of moving between folders. However most of the time I only focus on "module". It will also be easier to remove as module just to delete the sub folder and all it files are removed. If a project has more 30 modules it will be hard to find the file (Its possible to search but should be nice just have it in same folder). I been working with Drupal before that has this type of module system where you can easy add and remove modules (Might be that am used to to it and not yet familiar with this new this way of doing it). What are the main benefits of the first approach over the module way?
Is this possible to achieve in the express framework? If so any tutorials on how to set it up? Any other node.js framework support this?
I have two differents apps using a gruntfile.js and a package.json and when i launch locally my second app (providing only 1 functionnality, thats why i trying to merge it with the other), this works, but when i try to works the functionnality by merging the second app in the principal app, it says that modules are missing.
My principal app is the BPMN editor from: https://github.com/bpmn-io/bpmn-js
And the second app is the BPMN-diffing from: https://github.com/bpmn-io/bpmn-js-diffing
My BPMN_editor's Gruntfile is minifying BPMN_editor's .js files, then i tried to do the same for BPMN diffing's js files. but nothing is working, my node server wont run normally (while hes working without this BPMN diffing).
I dont understand how to use the bpmn diffing, should i make an npm install to install all dependencies of bpmn diffing, and then make an npm install of the bpmn editor to install dependencies ? or should i merge the Gruntfiles and the package.json files ?
Thanks a lot
Fantemis
If they are based upon two differrent configurations, I would prefer using a load balancer or a reverse proxy to load them on the server. Merging the projects takes a little more insights from you and a little effort. The effort always depends on the setup. I would give you a little tip, but I am not seeing a Gruntfile in your main principle repository.
A little insight into "Reverse Proxy vs. Load Balancer"
What is the difference between Reverse Proxy and Load Balancers
Alternative 1 (preferred):
You could however create a small node.js server, which is handling the serving of those two applications, like the following:
- bpmn_root
|- principal
|- diffing
Afterwards you just need to write a little script, that is building both things on the server you want it to be deployed, and then you just need to do node SCRIPT_NAME.js.
Further reading, and another post about this.
Alternative 2:
You can use Docker. I am not very aware of how to use Docker to power such thing, but it is "as simple as" creating an Nginx configuration, which is doing the reverse proxy stuff for you.
Alternative 3:
Using the load balancer, which is handling the reverse proxy automatically. This is also a little more complex and needs some more learning to do. You can find plenty of tutorials on this however on the internet.
I've started to convert my project to typescript and in a meanwhile I decided to improve code reuse between node.js backend, react web client and react-native mobile client.
Here is my project structure:
├ commons (code shared between backend and frontend, mostly type definitions and utils
├ clients (code shared between web and mobile clients, depends on commons: containers, utils, forms... )
├ backend (express server, depends on commons)
├ web (create-react-app, not ejected, no SSR needed, depends on clients)
├ mobile (react-native client, depends on clients)
What I've tried so far:
Symlinks. Could't make them work with react-native (see metro bundler issue).
This can probably be solved by using haul, but adds extra complexity by making haul work with typescript. Also, haul doesn't seem to work with Mobile Center, which I use for publishing mobile apps
Using rootDirs or paths in tsconfig.json. Typescript compiler doesn't merge/bundle outputs, so this means I need to support 3 different solutions to merge generated code. Also doesn't work well with my IDE.
Using WML. I tried two approaches:
Linking commons and clients to packages inside node_modules of web/mobile/server. To do this, I have to generate declarations, which is burdening because it requires exposing all imports (see this issue). Also doesn't play well with yarn, which will remove linked package every time it installs something new.
Linking commons and clients to separate source folder inside source folders of web, mobile and backend. This is what I use in current JS version of my project. It works, but it has some downsides:
Long relative imports (probably can be solved by supporting 3 different solutions for module aliases)
wml sometimes breaks in backround, which leads to some confusing albeit easy to discover errors
doesn't work well with hot reloading
I'm looking for a solution which is not too complex (requires minimal configuration on web/mobile/backend sides) and plays well with Webstorm.
It probably doesn't exist now, so I'd like to hear what other solutions people here use for similar project setups.
In the similar situation to yours I did the following:
commons gets published as a separate npm package. You can make it private if necessary.
clients depends on commons package and gets published to npm as well. Again - private if required.
web and mobile projects both reuse npm packages created above.
This is coming from the idea of 3rd party libraries being in Script to discourage developers from customizing them. It would encourage them to write extensions to make it easier to take in a new version of either library.
You make a good point about other developers mistaking the durandal libraries for customizable files.
But, you are not required to keep durandal anywhere. The folder structure can be whatever your heart desires. Because durandal does not impose any folder structure.. it only has a recommeneded default setup. There are benifits to following its pattern.
By keeping durandal as part of your application root folder. It keeps all your amd javascript files together in one root folder. This way when you run the durandal optimizer it can scan every subfolder to compress/minify/uglify all your html/css/js into 1 file. This is a nice benifit because its a 1 click build of your entire application.
Also, its a nice seperation because its a good idea to keep your 3rd party non-amd JavaScript libraries in a separate folder structure this way if you use a bundler to compress all your third party libraries into a separate file. The browser can cache your application separate from the third-party libraries. Because the third-party libraries don't change very often, whereas your application will probably be changing frequently.
But durandal's conventions are all completely configurable and you can put durandal in any location you like.
This is a convention that Durandal has decided to use to help keep your customer client code organized in an App folder and away from the 3rd party scripts folder, which gets pretty messy pretty quickly. It does put require.js in the App folder because of the way it relies on require.js and its AMD pattern. require.js is used to help locate all modules and load them as needed (in your App folder).
Is there something specific that you need that this is preventing?