Node.js, elasticsearch, mognodb, ext.js and Heroku sample application - work-in-progress

[Alexander Cherednichenko]

Hello! 

Me and team at my company (logicify, software consulting) have started node development around a year ago. We had then created a really simple app showcasing the tech stack, and now, after that year, we would like to share it with the community. 

This is a really simple but fully-functional application featuring data storage (MongoDB), search (Elasticsearch), cloud deployment (Heroku), serverside JSON API (node) and client-side UI (very basic extjs 4). Totally a work in progress rather than finished product. 

I think it may be useful: 

1. For learning - just get a grasp of the code in a bite-sized chunk (s). 
2. Sample for integration of technologies - it has quite full a stack though very small domain (books). 
3. Seed, or archetype app - we have been already seeding it twice as a skeleton for real-life application

So, the links: 

1. Github, code https://github.com/Logicify/nodejs-sample-task
2. my blog, motivation (why we needed that and how we use it?) http://lexaux.blogspot.com/2013/10/nodejs-elasticsearch-mognodb-extjs-and.html
3. and as a bonus - 2 slidesets from local meetup me and Pavel Knorr had last Thursday in Kherson (Russian language!). Just in case :) http://lexaux.blogspot.com/2013/10/two-talks-at-local-software-development.html

Thanks, and good night! 

Alex

[Floby]

Hey, really interesting stuff here.

I like how you tried to keep the dependencies minimal. However, here are my thoughts for what, in my opinion, could make this better

• Use something sexier than ExtJS. Like Angular.js or Ember.js. Better yet, all 3.
• Use Grunt for front-end assets management
• Add necessary files for deployement to Nodejitsu and Joyent in addition to Heroku
• Use 2 spaces indentation for javascript

IMO, this could become a great example app.

[Alex Kocharin]

On Monday, October 28, 2013 2:10:03 PM UTC+4, Floby wrote:

Hey, really interesting stuff here.

I like how you tried to keep the dependencies minimal. However, here are my thoughts for what, in my opinion, could make this better

• Use something sexier than ExtJS. Like Angular.js or Ember.js. Better yet, all 3.

Better yet, Jade. Simply because nobody seems to understand how to compile templates and use them on the client side.

I don't know about Ember.js, but Angular.js is largely overrated. I'd avoid that for a long while...

• Use Grunt for front-end assets management
• Add necessary files for deployement to Nodejitsu and Joyent in addition to Heroku
• Use 2 spaces indentation for javascript

Use tabs, pleeeeease. I understand that spaces is preferred in large projects because stupid developers don't understand smart tabs, but why do you suggest teaching beginners the wrong things?
 

[Alexander Cherednichenko]

Hello Alex, Floby! 

Thanks for your participation. 

As for UI - Totally Agree, capitalized. We had extjs as a requirement back then, and really only used it to illustrate node's REST API services. Will defo switch to something fancier later. We are not really happy with Ext in any way, especially after working for a while with it. 

Grunt, deployment descriptors to NodeJitsu and Joyent - yeah, great idea. If we add a couple of description pages on how to fire up the application, developer-in-study could have their app running in the Internet in like 5 minutes, mostly spent for account creation on hosters'. 

As for indentation - we'll look into that; really have to comply with all the projects' guidelines (which tell to use 4-space), but I also felt that's a little wider than it should be. 

Thanks all,

Will keep posted on significant updates to the app -- anyway we were planning to plug in fancy testing of everything (just as an illustrative setup) next.

Good night, 

Alex.

[Floby]

Thanks for your inputs alex's.

In my book, jade sucks ass, as does any templating on the server-side. So you see, opinions infer. My suggestion to use javascript MV* frameworks is in fact because they are so hip. Alexander is trying to gather interest, this is probably the best way.

for code formatting, just feed your code through jshint or jslint. This is the standard for javascript.

[Alex Kocharin]

29.10.2013, 13:05, "Floby" <floren...@gmail.com>:

Thanks for your inputs alex's.

 

In my book, jade sucks ass, as does any templating on the server-side.

 

Yep, that's what I'm talking about.

 

Jade can be used quite well for hybrid approach, by which I mean creating the same templates on the server-side and updating them on the client-side without reloading.

 

But a lot of the people think that it's a server-side only engine, and that's exactly why people need to teach about its possibilities.

 

That's why angular.js sucks by the way. You can't use it on the server side, so it is useful only for a few web applications where client-side js is an actual requirement.

 

 

So you see, opinions infer. My suggestion to use javascript MV* frameworks is in fact because they are so hip. Alexander is trying to gather interest, this is probably the best way.

 

for code formatting, just feed your code through jshint or jslint. This is the standard for javascript.

 

Jslint is an opinionated crap. Jshint is better, but only because you can configure it properly. Default codestyle imposed by both these engines is a crap.

 

I actually tried to use jshint for a while. And just once in all the years it successfully catched an error for me. I still remember that one case, it was like that:

var something,

    foo,

    bar;  // <-- this

    baz,

    qaaz;

 

I avoid semicolons since, but I still remember that case for some reason.

 

Anyway, running jshint to fix an errors in the code isn't really worth it. Running jshint to check your codestyle is just plainly wrong. It is NOT the standard.

 

 

--
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Alexander Cherednichenko]

Hey Alex, 

there's the same holywar in Java world about Checkstyle. And btw, the error caught by the jshint there should be really caught by the 'use strict' and some unittest (mocha, for instance, catches mem leaks even w/out 'use strict').

Guys, again - that's really a sample of node.js layers; client is just showcasing the way restlike APIs may be easily exposed and the tech stack which allows for quick creation of such APIs. I should have given more stress on that in the original email, sorry. 

Code styling really is an opinionated stuff, I know people totally nuts about Coffee and its haters. And yes, I can understand both of them :)

So let's keep this idea-centric, not whitespace. 

Btw I also had that feeling that Jade is rather for serverside rendering than for client-side. Anyway, if we do client rendering with it we'll need something to plug in for the MV* (backbone?).

Cheers,

Alex. 

2013/10/29 Alex Kocharin <al...@kocharin.ru>

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/yjyHVWlDPjU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Alexander Cherednichenko

[ the only way out is the way up ]

[Alex Kocharin]

> Btw I also had that feeling that Jade is rather for serverside rendering than for client-side.

 

You are correct. If you do pure client-side rendering, other template engines might go just as well.

 

But simple applications shouldn't do pure client-side rendering. Older browsers don't work well with it, NoScript can cause trouble, and search engines won't index it correctly.

 

So you will eventually want a pre-rendering on the server as a fallback. But that's the point when pure client-side template engines start to cause trouble. You can't have native DOM on the server, so it won't be fast enough to run them.

 

And that's why you should use jade. It will work on the server just as well as on the client, right? :)

 

---------------------

 

I understand that you're trying to use REST api. And in fact, that's what I'm usually using.

 

The trick is: you can separate your REST api server and your webserver. It is a two different tasks. You can mix them in one node.js process, but they should be two separate express.js applications.

 

Something should serve your assets (images, css, etc), right? And it isn't a place for them in the API server.

 

But if you're doing a webserver as a separate applications, it might as well compile templates for old browsers and search engines. Modern browsers will still access API directly, so it comes with no cost attached.

 

That's how I design my systems usually, and I'm quite convinced that it's the best way to do most of the applications (except for very complex client-side ones like gmail or online spreadsheets).

 

It might be too complex for the example though. If you just like to serve all your static files from CDN, and use something like Jekyll to generate all static, this would be obviously wrong choice.

 

---------------------

 

Anyway. It all depends on a assets build engine you're using. I know grunt works, I know requirejs works, and I wrote some builders of my own, but it's important to use one. Which one do you use by the way?

 

The point is, and that's where most people go wrong: Jade templates can be compiled to a javascript functions on the server by an asset builder. You get function(vars) which returns string you insert to a DOM. Client-side never see actual jade templates, they just see compiled functions.

 

So, it's as fast as it can be (because what can be faster than pre-compiled js functions?), and you still develop using jade language instead of html (html is ugly in my opinion, so...).

 

I think I had an example of such setup somewhere, because I used to write some article about this before, and I think I can help you with this one if you like.

 

 

29.10.2013, 14:06, "Alexander Cherednichenko" <lex...@gmail.com>:

[Floby]

I guess I was totally convinced at "it's crap crap crap".

[vipin singh]

Hi I am new on elastic search. I ma developing an App with MEANJS(Mongodb, Express,Angular,Node). But not getting the idea how to display the elastic search content in template. any suggestion will be very helpful for me.

[Alexander Cherednichenko]

Hi Vipin,

It's nott really related to the ttemplates. You can look into the sample app about how to query ES instance via the REST api. As soon as you have API result, you can then use it as any variable and just insert it into the template as you like.

In our sample app we don't have server-side templating, instead we do expose our own API to the outside world, and consume it with the Ext.js application.

Hope that helps!
Cheers,
Alex.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/yjyHVWlDPjU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/4dac50e5-a292-406b-b06f-a21b5cd87c5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.