MEAN.JS 1.0 Roadmap #1666
Comments
|
FYI Ping @meanjs/contributors @meanjs/core @rhutchison @liorkesos @simison @jloveland @ilanbiala @trainerbill @hyperreality @vaucouleur |
What I think would be the best is to use some decorator/driver/plugin system that let other people use different options, i.e., someone thinks RethinkDB is the best tool for the entity but for other entity that could be a CouchDB, Casandra, Arango etc. etc. What about assets serving? People might want to use other stuff than express(don't know other but that could be an issue). In Drupal, we solved it using plugins or maybe swappable services(originated from Symfony), and for the different entities, we solved it by using entity storage which means we can store entities in any storage(NoSQL, files, whatever). Only rethinkDB implemented for now but you have the infrastructure for that. |
|
It's a good news.
And finally i prefer Some other questions ?
|
|
Great news, I would love to give a hand in this!
I also prefer the angular-cli tool. For now, it's much more popular then universal and have more rapid development.
I'm not sure about it. Couchbase have some very good momentum but it can be just the hot new good thing that will be replaced be another hot new good thing in a year or so.
I think this is a good approach, the
I think option 1 or 2 are the best, and I lean towards option 1 because it's simpler and I don't see any big advantage to option 2 on 1 (I would love to hear if i'm wrong). Other:
|
|
@lirantal I like those general directions. The client/server refactoring is an excellent idea. I also agree that the database options should be revisited (currently moving my code base to sequelize/pg, the work by @francisdaigle and others was helpful). I guess the language options should be discussed, (peacefully !). Furthermore, it would be helpful if we could have a general ordering of the tasks/goals (not dates, an order), for example: 1) the client/server refactoring.. 2) this.. 3) that.. So that progress/commits can be done orderly (in order to minimize commit conflicts). The name of the project could be revisited, not only because MEAN.JS will not necessarily reflect the stack any longer, but also because the current name attracts a lot of "not meanjs specific questions" on the forums; a name that is "not based on acronyms" would help. Also, still from a marketing/communication point of view, it would be great if the project had one major feature that set it apart from the other projects, something that the other don't do (or don't do properly). |
|
Initially 👍 |
|
Adding my 2 cents B. I like the client/server decoupling. Angular2, angular-cli, material for the frontend. I am currently working on a design for the backend that would be based on complete configuration and require very few lines of code for the server side. The general idea is to have a
Maybe I am dreaming.... Let me know your thoughts.. |
|
Hello Sujeeth,
Your system sounds like the package system we have in place in mean.io .
We're currently in the exact same phase contemplating and building a
roadmap for mean2
I think we should attempt to work together and remerge these communities
and maybe try to build something together. There is a lot of overlap and
stuff to share and many of the people , technologies and targets (including
my diminishing involvement) are not rellavent any more.
So meanjs community... Maybe I'm dreaming ... Let me know your thoughts...
:)
…On Dec 9, 2016 6:23 AM, "Sujeeth" ***@***.***> wrote:
Adding my 2 cents
A. I agree, current version can restrict feature changes and support
maintenance until the stack can build a stable version with Angular2.
B. I like the client/server decoupling. Angular2, angular-cli, material
for the frontend.
I am currently working on a design for the backend that would be based on
complete configuration and require very few lines of code for the server
side. The general idea is to have a
- Plug-n-Play system giving user options to add/remove/switch
parts('plugs') of the server components. Ideally have folks write different
plugs for the project. A db plug for mongodb and a db plug for couchdb etc.
And the end user can choose what he needs.
- Follow a microservices like approach and each service is independent
of the other. The DB plugs are designed only to handle data. The session
plug handles sessions either JWT or cookie based. The Authentication plug
handles auth. Logging plug handles logging, etc. The user can enable
features as required.
- Also package the project to npm so that updates can be made easily
without the need to merge all the changes and spend time resolving
conflicts. A simple npm update should upgrade the server side with ease.
- And hopefully try to implement the REST services with dynamic
configuration. Because every API does the same job- takes an input, either
updates or pulls value from db, does compare and responds back. Essentially
the configuration file has a route, the api to be called, the input to
pass, and fields to expect. The API is built to do just its function,.
- The user can just setup a configuration file and forget about the
server side code and focus on client side
Maybe I am dreaming.... Let me know your thoughts..
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1666 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAO9I54rLBGYHiYQsRnp1juwxv3Ds4nFks5rGNfXgaJpZM4LDjct>
.
|
|
Not exactly, mean.io has a cli to generate the boilerplate. Once done, we customize it and it can not be upgraded again using the cli. My suggestion was more like how express works. You just require the package and leave the rest to it. And if new version is available you just upgrade it. The package will have apis and we pass arguments and invoke them. Was throwing this thought out to see if it sparks some ideas. If someone thinks my idea is not crazy let me know and I can explain in more detail with some sample code I have. In either case, I think it deviates from this road map planning for meanjs so I'm going to shut up now :) so focus can be on current road map suggestions. |
|
@sujeethk Featherjs, among others, works a bit like this. Authentication, for example, is a plugin. In your vision, is it mandatory to "build this plugable system", or is "fitting meanjs into an existing-plugable system" an option ? https://docs.feathersjs.com/ |
|
@vaucouleur Right, featherjs is somewhat similar to what i was suggesting but also extend this to other services. The idea is to refactor the existing code into a plugable system. This gives the ability for contributors for example someone interested in CouchDB to write a pluggable code that can be added to the project. The configuration file controls which DB to use and defaults to MongoDB, but can be overriden by the user if he chooses a different DB.
What I mean by a plug? This plug-and-play can be extended to all features and just exposing a common API for each service. I am sorry, Its been a messy week, and i am not able to put in words what I envision. But did a very rough prototype, checkout the project named eezejs in my repo. and the testprj repo shows how the config files are setup and how the eezejs is used. Didnt find the time to clean up or remove passwords from the files, no biggie though. Feel free to provide your thoughts. I know this would be a --wide-- deviation from what the current roadmap is. So let me know if you want to take the discussion offline or continue here. I'm going to stop polluting this thread further until someone is interested. |
|
For the past year I have been debating this same thing. I have went from trying to write my own frame work using many of the principles that @sujeethk mentioned, but things become so complex and I just wonder why am I doing this. I tried Meteor which is kinda what is being proposed, and it is just too much and reduces customization. I always go back to just using angular-cli. The only thing that is really lacking is:
But now I am asking myself why I even want a server side. If I am prototyping I can just import mongoose into the client app and directly query the DB. The only time you really need a server is DB interaction and third party api interaction where you need secure keys. So really all I would really need is a lightweight server application in my angular-cli project that I can use --proxy with. Probably use HAPI or Restify for the server and then just build out really small reusable REST modules/routes to do only what is needed. Then I can spend most of my time writing ng2 client modules. Client side modules can be written independent of server side as you can just coax the data into the format that the client module needs. Then a person can use any backend they want and just remap the data to make it work with the client module. |
|
@sujeethk It makes perfect sense, and it's a well respected approach, see for example this article by Parnas, that dates from 1972 [1]. So modules, with a well-defined interface between them. I guess some proper type system to support those interfaces. May be some design-by-contract to properly describe those interfaces (pre and post-conditions, etc.). And of course, proper versioning and proper dependency management. Start this infrastructure work, convince a bunch of people to write modules.. then maybe some refactoring 1 year later because version v1 is never perfect.. and a thousand of bug reports later (2 years later), we'll have yet another modular stack in the javascript world. But it's ok.. because then we can have an army of bloggers that compare our modular stack with the other modular stacks -- and choice is good, right ? Or, we can try to fit meanjs into an existing modular stack. [1] https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf |
|
multi-language support? I mean internationalisation of the frontend. |
A. MEAN.JS Angular v1 (current stack) Roadmap
I agree with this approach. We need to continue with the existing roadmap.
I plan on continuing my participation in supporting, and enhancing, the existing MEANJS project using Angular 1.5.x B. Future MEAN.JS with Angular 2
Definitely Angular 2 (and I personally would use Redux for managing state in my own apps as someone mentioned above). I'm generally fine with using
I think we should keep the MEN aspect of the architecture intact. MongoDB is a fine choice for a lot of applications. For me, I've yet to be convinced that SQL Server, PostgresSQL, or the other database frameworks are a better choice. However you look at this, it probably isn't the most relevant point to dwell on. For small projects, and startups, MongoDB is an easy choice to develop your schema & application initially without much overhead. As in most applications, there comes a point where the database size, and performance optimizations become more relevant than the ease of development that MongoDB provides. This is where our responsibility comes into play. We owe it to our user base to provide a framework that can be easily changed/customized to fulfill individual needs. We should abstract the database logic away from the other aspects of the server implementation to make it easy to move from one database technology to another. I've already started to move in this direction with my own projects. I'm trying build out my models in a POCO like fashion, and I use "data" services that are knowledgeable of the particular database technology I'm using.
De-coupling the server-side & client-side would be one of my main priorities with this endeavor.
I do like the idea of option 3 (and cloning would be easy as Liran pointed out). It seems very logical, and it could further demonstrate our intentions with the de-coupling of the client/server; even more so, it would be more in line with a typical scenario where the server is a stand-alone API used by many different types of clients. Otherwise, option 1 is easy too.
If maintaining a CLI (generator) of our own wasn't a concern, then I would be ok with just building out our own Angular2 front-end. However, we're having issues keeping the generator project up to date, so this does push me to favoring the use of |
|
@trendzetter The angular-cli has couple of PRs about it, so they will handle it and we will get it "for free". |
|
Have you thought about immutable state? If so, maybe this project of mine can help. It is my attempt to reconcile some disparate Angular 2 approaches and provide a few example features. Primarily, it uses Angular-CLI and Redux for immutable state. Immutable state is a pretty core idea for an app so if you haven't considered it, I might suggest doing that. The example I made from other examples is mostly front-end with a little express server for simple json file i/o and authentication. One thing about Redux is that it encourages you to shape your state the way tables in a normalized relational database are. That could possibly impact a database decision, but there's a library, normalizr, for dealing with nosql data too. |
…anup (#1685) * removing unrelated module * defining a global variable * restoring default user profile image * removing unncessary test * fixing tests to not run nodemon * updating lint task to run in the test task
|
From 4d82174#commitcomment-20287517
|
This. Offline first, totally. Gear it towards mobile; it's already really important now and it's gonna get tremendously more important in the future. |
|
@simison totally what I started working at :) |
|
@meanjs/contributors @meanjs/core @simison @dancancro @nirgn975 @RoySegall @vaucouleur
The benefits of (2) are clearly a new repo and all that it entails (clean wiki, issue, etc), although my concern is that Need some community input so please share your thoughts. |
|
@lirantal , it is a good idea to keep them separate repos for each version so we can support meanjs and keep learning new things and improve things. |
|
Please note that Angular folks don't want us to use "v2" on projects to refering "Angular v2+" stuff: https://angularjs.blogspot.lt/2016/12/ok-let-me-explain-its-going-to-be.html I'd say try to keep it at main repo. It'll be inconvenient for a while, but if you think a year or two ahead, it really is the most clear approach. Imagine if other frameworks like Wordpress or Django would create new repositories for each major version? It's perfectly fine to have a branch where new major version is being developed. When new updates to v0.x come (it'll be less and less over time), it's okay to tag new 0.x/1.x versions separately. See e.g.: https://github.com/twbs/bootstrap/releases You'll just have to do a switch from v1 branch to master at some point, which might be painful for some. |
@simison Under most circumstances, I'd agree with this approach. However, the work being put into the meanjs2 branch isn't merely a new major version of the existing meanjs/mean project. It's clearly a new project, that will bring on a different set of dependencies, and some dependencies that are the same could have different versions. The latter could create some serious headache when contributors are switching back & forth between master & meanjs2. The current (Angular 1.5.x) version will most likely stay around for a while (2+ years), as a lot of users that are new to MEAN, or some that require a more mature (stable) Angular version, among other reasons. Personally, I will continue to support clients using Angular 1.5.x (or 1.6.x) & base new projects off what's currently in meanjs/mean for clients that require less risk (or can't mange the resources required to maintain an Angular 2 app). I can only assume other devs are in the same boat as I am in this regard. This is my suggestion for the new repos: In the future, or whenever someone wants to take it on, we could have additional repo's: To me MEANJS2 is too unique to consider it a major version of meanjs/mean. As to the eventual relevance of the meanjs/mean repo, it shouldn't matter if we move forward with using a more concise naming convention for our projects (repos). Lastly, there's little chance that mean-api & mean-angular would go unnoticed. We'd have a clear note on the readme of meanjs/mean that will point those interested in the newer version to the new repo's. We already see quite a bit of interest in contributions to the new implementation of MEANJS, so the momentum will be realized almost immediately. I worry, that the pain of the maintenance nightmare of doing development in the meanjs2 branch will be too much for some contributors, thus hindering progress in this endeavor. |
|
@mleanos my comments on the above notes you made:
If we separate the repos we also doom a split of the community because inevitably users will spend time on one of the repos, not both. Lastly, if Angular 1 will still be kicking in 1-2 years the beer is on me buddy :-) |
|
About 0.6.0 - what outstanding PRs do we have at the moment that must get in? can you review? As for Riess.js, I'm glad you guys are bringing this in again as I definitely need some energy juice there to energize since I got caught up with job change in the last year. |
|
I addressed a few issues with quick PRs. Triaging issues:
I removed some old docker related issues from 0.6.0, they can wait. |
|
Sounds good, 0.6.0 on the way! :) |
|
@lirantal ready for 0.6.0! :-)
|
|
Let's get #1845 in 0.6.0 too :) |
|
let's sort out the package.json clean up real quick and I'll go for 0.6.0 |
|
Looks like we're good for 0.6.0, great stuff guys! |
|
When the 0.6.0 will be available to use .If i am not wrong we are getting angular 2 Major update in this release and, one more thing can we get Proper Documentation for 0.6.0 this time @lirantal ? |
|
@umairch you can basically just clone the current 'master' branch and "get the release". Our formal release process of 0.6.0 is really just cosmetics with a version bump, changelog and tag, because we don't roll out anymore the mean.js generator package to npm. Also sorry but no new Angular in this release. Would love any help on updating the documentation for the meanjs site if you want to send us some PRs on the other repo (https://github.com/meanjs/meanjs.github.io) |
@lirantal sounds like a good idea, @umairch let's help with the documentation for 0.6.0 |
|
For Sure Sir @shakeeltariq. |
|
Hello ! New year, it's time to start on angular :) ! We needed a Stack with angular 5 with some friends (beta for a project). Nothing definitive but a good start:
we call this MEANie for the moment. The next steps for us are :
We would be happy to have your feedbacks on this begin of work, and launch the next version of meanJs with you. Everything is in beta / alpha for the moment. ( I tag people who worked or followed or used this Angular part today for their information @techla @farhatmo @cherifa-ghersi @leodonny @Jrmy-b ) |
|
Hello
Pierre Brisorgueil,
That's amazing, but i still learning mean stack kinda a beginner I don't
know if that suits for you or you need only people with experience to do
that. am still in the learning path,.
but I hope I can help for anything thing i can so please tell me what I can
help when still beginner.
*Thank You For Your Consideration.*
*-------------------------------------------------------------------------*
*Ahmad Muhammad Waddah*
*Mail : [email protected] <[email protected]> *
*Mob : +201141591695*
*Others : Whatsapp, Viber & Hangout*
…On Thu, Jan 25, 2018 at 3:57 PM, Pierre Brisorgueil < ***@***.***> wrote:
@lirantal <https://github.com/lirantal> @simison
<https://github.com/simison> @mleanos <https://github.com/mleanos>
Hello !
New year, it's time to start on angular :) !
We needed a Stack with angular 5 with some friends (beta for a project).
We are using meanjs for lot of projects and we decided to use @lirantal
<https://github.com/lirantal> work on riess.js (just one edit on jwt
<https://github.com/weareopensource/Riess.js/commits/master>) for a new
stack, and create a client part.
Nothing definitive but a good start:
- material
- angular-cli
- Nx
- ngRx
- client <https://github.com/weareopensource/Angular> and server
(Riess.js fork) <https://github.com/weareopensource/Riess.js> in two
repo
we call this *MEANie <https://github.com/weareopensource/MEANie>* for the
moment.
The next steps for us are :
- host a demo
- some fixs
- travis build
- e2e client server test
- Linter & Indent
- documentation
- communication
We would be happy to have your feedbacks on this begin of work, and launch
the next version of meanJs with you.
Everything is in beta / alpha for the moment.
*( I tag people who worked or followed or used this Angular part today for
their information @techla <https://github.com/techla> @farhatmo
<https://github.com/farhatmo> @cherifa-ghersi
<https://github.com/cherifa-ghersi> @leodonny <https://github.com/leodonny>
@Jrmy-b <https://github.com/jrmy-b> )*
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1666 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AWpM7A92UxDi5rmV4WdEnxs7T_OLh_RVks5tOIgygaJpZM4LDjct>
.
|
|
Hey guys, I've not read this all yet. Maybe we should cut/paste and use the gitbooks to maintain the choice cuts from this document as a spec. It could event be done nicely as a concurrent repo of pseudo code. This way the most recent version can be on display for those interested in jumping in without reading the back-story. It also keeps revisions so it can evolve alongside the codebase. |
|
hey @PierreBrisorgueil, thanks for bringing refreshing news and really cool to hear you've put these efforts to work :-) Since it seems there's real interest and practical work around this initiative I'd be happy to jump in, especially to complete the server-side since I felt bad for leaving it half-way there. A bit of semantics with the name - due to technology pains of limiting yourself to a specific tool I chose a generic name (Riess) and steered away from any sorts of acronyms. |
|
Hi everyone, I introduce myself, @techla, I am happy to meet you. I am an Angular developer and very happy to see that the project finds people interested in. I worked on the Angular part, based on the first @farhatmo implementation that I modified by introducing ngrx and NX, which allowed me to rethink the modularity of an angular application, inspired by the examples provided on the repository NX. I have many ideas in mind to enrich the front, and I will be glad to contribute to the project with you ! best regards |
|
Hello @lirantal good news to read :) ! let's go ! I've created a community we're working on right now called Weareopensource (web). The concept that I would have liked to succeed is a repo by technos, node angular swift ... and parents repo named Stack, who called two technos repo. for example :
or something like that, we can change meanie by Riess or whatever .... another naming rule ! :) Weareopensource would interest you or would you prefer that we launch a new community from scratch ?
The most important thing is to have a common place to share the Roadmap and issues :) the rest does not matter to me ! |
|
I can write back-end (using node.js/loopback.js/express.js) and frontend ( Angular2+, webpack, etc. ). Please tell me how I can help you ? |
|
@kuldipem good news ! to see others are interested, just wait for us to agree on the community to launch with @lirantal @simison @mleanos And then we can start, clarify the roadmap, create issues & boards github to work together, after this, every body will be free to pull requests on the project :) |
|
💯 👍 agree with any activity going forward. :-) My general advice for any open source activity would be:
Thank you! ❤️ |
|
Yes, I'm agree with you @simison . Technology trends are changing dramatically, so we need to decide quickly and start working !! |
|
@PierreBrisorgueil thanks for the invite and the context. I really want to push things forward but I always end up too busy with other projects. |
|
Ok, so let's go 1/ I have cleaned up the organization weareopensourcewe have now two orga :
2/ We have now this :The Stack : With two subtrees : Node part is a fork of Riess.js. What I propose, is to rename MEANie to RIESS. RIESS will be the full stack, based on two repo Node and Angular. So Node will leave the status of FORK and become an independent repo. And i invite @mleanos @lirantal @simison to the community and this three repo with @techla , and everybody to make PR. MEANie (or RIESS if we change the name) is already ok, README up to date, you can test it and contribute here This is an example of project on it : Storytelling Graph builder for presentations 3/ So we can now start to workWe started listing issues to draw a Roadmap. We classify them by type & stack : https://github.com/weareopensource/MEANie/projects/1? |
and others
In continuation to Angular 2 discussion in #1591, I would like to try and set some baseline agreement and proposal for the future of MEAN.JS:
Action Items
Please steer the discussion towards the following action items that we wish to reach agreement on in the following order of priorities:
angular-clivs any other tool), frontend layout/components lib (material, bootstrap etc)A. MEAN.JS Angular v1 (current stack) Roadmap
B. Future MEAN.JS with Angular 2
Rather than a check list let's try to reason about the direction considering the following:
angular-clibecause I believe the scaffold tool will dominate the starter projects. It also means we don't need to maintain our own and we can make continuous updates and merge the project with updates thatangular-clireleases.expressjsseems like an obvious point due to popularity and community wealth, I'm not yet sure onMongoDBfor the future although I'm willing to keep the MEN stack technologies for now until someone can testify if there are really better alternatives (i.e: koa + couchbase)Where:
/client will have an angular-cli bootstraped project
/server will have our MEN-based project, completely API-based
The package.json in the top root is simply for managing the npm scripts to run the project
Advantages in this approach is due to the de-coupling of the frontend and backend technologies, users can "take" the server api side and use react for the frontend by simply exchanging our ng2
/clientfolder with their own client folder.Disadvantages could be that it will be harder to support universal-based projects.
The text was updated successfully, but these errors were encountered: