I was looking at a similar decision albeit on a much smaller scale but with quite a lot of existing non js backend software. In my eternal quest for simplicity eventually I decided to rewrite it all using Zappjs which is a sort of wrapper with express, node, socketio, coffeescript, coffeekup-views. Being risk shy I stuck to my existing db structure but replaced it with the Mariadb drop in so I can do some async queries where it makes sense and hopefully avoid any license issues. Although I have Linux and dev & debugging background as a total js newcomer I may have missed some of the finer points. But customers seem to be happy with the first pieces I rolled out and I am quick on my feet changing and publishing almost every week and rewriting the other stuff little by little as time permits. Personally I found it more efficient to integrate bits from existing modules into my code to keep it all very compact and readable for me and with the lowest possible overhead, of course. One also learns more and thus gains long term productivity. No regrets, all is stable, with a good response times so far and quite easy to manage after the usual steep js+async newbie learning curve. After all it's all about productivity and flexibility and freedom. Hope this comments helps you. And hats off and warm thanks to the maintainers of Node and the surrounding tools!!! You're my heroes.
Karl El lunes, 17 de diciembre de 2012 11:52:06 UTC+1, panyasan escribió: > > 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]> 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
