I looked at Meteor and at first thought that it might be a good fit. However, as I said in my post, I want to stick with the NodeJS model of doing things and not use a completely different (synchronous) paradigm. But that (as well as not wanting to use RoR) my personal choice, nothing I need to bore you with. Please tell me if I am getting on your nerves, after all, this seems to be a technical forum, not an application design forum. I am not saying I am right, I'm just responding to your posts and trying to defend my claims.
What I find interesting to debate is if your general claim (each project is radically different) really is true for everybody. It is true for you of course, and probably for the majority of people posting here. But when I look at my - admittedly anecdotal - experience, I can say that all of the major applications that I build (or would like to build) need exactly the same kind of backend. To make it less theoretical, here are the applications: - A bibliographic data manager<http://bibliograph.svn.sourceforge.net/viewvc/bibliograph/bibliograph/trunk/bibliograph/>, used for collecting, managing and publishing bibliographic references. Target audience: research groups, university departments - A twitter-like intranet communication tool<https://github.com/cboulanger/LogBuch>with a calender, used in an organization to document business processes across different companies. Target audience: company staff, administrators. - A staff scheduling program, used for organizing service shifts at conferences: Target audience: students interested in working a shift. - Planned, but not implemented: a web-based IMAP administration/backup/copy tool. Target audience: Company email administrators - Planned, but not implemented: a conference organization tool specific to the organization of session-based conferences. Target audience: Academics - Planned, but not implemented: a newsletter tool with very fine-grained distribution options. Target audience: Company PR administrators. That's only three existing projects, so my evidence is tiny compared to the number of projects you or others have already done. But they including the not implemented ones are all very different and have different audiences, and their backends have a lot in common, at least, however, the following three elements: - They manage the users that sign up and login and out. Therefore you need the logic to manage the user data (name, email, other properties), and a GUI administration tool to do the management. That is very generic, to be sure, and doesn't cover all the different properties that you might want users to have. But for rapid application development, that is enough to get you going. - They manage access control, i.e., you define resources on one hand, and roles and permissions, on the other, and then assign roles to users, which in turn have permissions to access resources. That is a generic, but very powerful paradigm, which fits - at least in my view - all of the use cases that I can think of. This access control system can be displayed and edited - I have already done that in PHP - in a visual editor. Again, very generic, but if you work with named resources (which can be a database or a button on a widget on the client), it seems to me to be the right tool. - Data modelling and persistence. I don't need to talk about this, it's been solved by many different libraries (such as mongoose), so I am just adding it for the record. Full-fledged systems like Wakanda even provide visual editors for models, but that's not what I need. So again, what you're saying is that trying to solve thins generically is the wrong approach. It might be true for the majority of production-grade apps, but I would know exactly how to hook the application-specific requirements into this one-size-fits-all system. Ok, but enought of this. Thanks again for your thoughtful comments. Am Sonntag, 16. Dezember 2012 23:36:20 UTC+1 schrieb Raynos: > > > On the very contrary, my argument was that it could be worthwhile to > make something that you, as full-time developers, do for every new of your > projects -- the wiring together of all these different parts -- into a > collaboratively maintained project, which I labeled (or maybe: misnamed) > "application server". > > That wiring is different for every author. It's different for every > project I've done as an author. It's different for every base framework. > > If you want this you fit right into the target audience of meteor and > should probably be using that. Alternatively consider using ruby on rails, > it does the things you want reasonably well. > > > There were a lot of loose ends, the stuff didn't naturally fit each > other, and I had to spend more and more time on the "glue code". > > Your also forgetting that application architecture is application > specific. A generic boilerplate won't fit most apps. the reason things dont > naturally fit is because you didn't architect your application base based > on the application, you tried to use something generic. > > On Sun, Dec 16, 2012 at 3:31 AM, panyasan <[email protected]<javascript:> > > wrote: > >> On the very contrary, my argument was that it could be worthwhile to make >> something that you, as full-time developers, do for every new of your >> projects -- the wiring together of all these different parts -- into a >> collaboratively maintained project, which I labeled (or maybe: misnamed) >> "application server". > > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
