On Fri, Mar 10, 2017 at 5:49 AM, Alexander Kanavin <[email protected]> wrote: > Hello, > > I've done some research around MEAN stack and how Yocto could support it, > and here are the findings. > > *What is MEAN* > > MEAN (http://mean.io/) is a Javascript framework for writing web > applications with a client-server architecture. It's comprised of four major > components: > > - Node.js, the standalone Javascript interpreter that does not need a > browser to run > - MongoDB, a C++ NoSQL database server > - Angular.js, a javascript application framework > - Express.js, another javascript application framework (not sure how the two > interact - I'm not a JS specialist) > > The major selling point of MEAN is that it is a 'full stack'. This means > that both client and server side code is written using the same language, > and shares many of the libraries. This is in contrast to the traditional > LAMP stack, where server code is written in P* (Python, Perl or PHP) and > client code is written in javascript, and presumably hiring developers with > the right skillset is harder in such circumstances. > > Starting a project in MEAN is very easy - the (slightly exaggerated) example > from the website frontpage is: > > $ sudo npm install -g mean-cli > $ mean init yourNewApp > > *Why does Yocto need to support this?* > > At the moment, it really does not. But we need to move with the times; if > Yocto users want to put a MEAN app on their devices, Yocto should not get in > their way, or declare that it isn't supported. There is a trend towards > using node.js on the server side, and it will probably trickle over into > embedded space as well. > > *What are the difficulties?* > > Placing node.js and Mongodb into images is not complicated. We have recipes > for both (meta-oe has an outdated version of node.js, but there's also > meta-node layer, which is totally up to date with upstream). The > complications arise from the way javascript world handles project > dependencies (see my previous email for a deeper look into this). It works > like this: > > - after initializing the project like above, you need to change into the > project directory and do this: > > $ npm install > > - this recursively pulls all of the dependencies (including angular.js and > express.js) into the node_modules directory of the project tree. Developers > don't need to know or care what they are, and where they come from (and it's > implied that licensing is not a worry either); the resulting set of > libraries is bundled with the application and is not shared with other > applications. As long as npm install completes without an error, that's all > you need to worry about. > > - unfortunately for us, the list of dependencies is truly enormous. The > bare-bones MEAN app pulls in 1087 dependencies - and each of them has their > own license, version, and upstream repository: > > $ ls myNewApp/node_modules/|wc -w > 1087 > > *What do we do with the 1087 dependencies?* > > There is support in bitbake/devtool for dealing with npm-based projects - I > didn't have time to try it (and it's also at the moment broken for the > master branch due to rss), but it would probably not handle this very well: > > - it reimplements 'npm install' as a custom fetcher and dependency resolver. > I believe this is not the right way in the long run: we should let 'npm > install' do its job, and inspect the tree after it's done to get the > information we really need. > > - the license information for all of the dependencies is written into the > recipe, which makes it unnecessarily large. It is not clear how that > information should be updated when needed. > > - also, the dependencies are locked down through a separate lockdown file > created by devtool, but it's not clear what to do when the lockdown file > doesn't match reality, or when it otherwise needs to be updated. There > should be a common, documented mechanism for all of this - see my previous > email :)
seems like say LAMP stack. I would suggest a meta-mean on git.yp.org and may be merge meta-nodejs there as well. -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
