Can somebody give me some insights what is the difference between Netflix Zuul version 1.x.x and new version 2.x.x?
Seems that both product line are maintained.
And version 2 is using Guice for DI and there are some difference in Filter implementation. ??
I got really nice answer from #NiteshKant on GitHub from Netflix:
Unfortunately there is no documentation about the motivations for 2.x and what it changes. I am intending to put together something in the coming weeks when time permits. As of today, I hope the following suffices:
What is 2.x?
2.x intends to move zuul from current synchronous execution model to a top to bottom asynchronous processing model. This includes using non-blocking I/O (practically RxNetty as the networking library) and application processing semantics (RxJava as the asynchronous library)
Why 2.x?
Intentionally staying away from proofs and benchmarks, the motivation for 2.x (essentially moving to an async model) is to have better resilience, control and performance characteristics for all applications inside Netflix.
Status
The current status of 2.x is snapshot. We are currently testing the new filter model (async) with blocking I/O inside netflix. Once we are comfortable with this change, we will be testing the changes with non-blocking I/O. After that we will be publishing release candidate and release artifacts.
Should you adopt 2.x now?
2.x is really very bleeding edge (sorry for the cliche) so we will be changing APIs, deployment models and implementations. So, unless you are prepared to take the burden of keeping up with these changes, I would recommend waiting a while.
Also, 2.x comes with lots of changes in usage, so most likely you will have to change all your existing filters, if any. This can be a big task depending on the current usage. So, it is your decision on that front in terms of ROI.
There are more related links to the subject on Zuul 2.x:
https://github.com/Netflix/zuul/issues/121
https://github.com/Netflix/zuul/issues/106
https://github.com/Netflix/zuul/issues/139
https://github.com/Netflix/zuul/issues/130
Related
I had selected sproutcore as a framework right before Ember forked from sproutcore. I am left uncertain of which way to go and a bit frustrated in the apparent dilution of efforts caused by the fragmentation - as rarely does that lead to better things. The efforts of Sproutcore 2.0 (now Ember) seemed to be going in the right direction of modularization and reuse of other javasript components (jQuery), however it is really unclear from an outside view why the two efforts had to split... couldn't we have modular code, and a widget library module too?
The main questions are:
What are the effective differences between the two efforts?
What is history of the split?
What is sproutcore future, where is it going now?
Is Ember going develop to be a complete replacement for sproutcore?
As someone who has both a Sproutcore app and an Ember app close to a production launch, I'll take a stab at your questions (re-ordered for clarity). All of the below is what I've observed with no inside knowledge. A bit of it is speculation, so I've enabled wiki mode on this answer, so that more informed people can correct details.
What is history of the split?
Here is what I've pieced together:
SproutCore was created by Charles Jolley's company Sproutit as the basis of their Mailroom product in 2007. Jolley later joined Apple and Sproutcore was used to build the original web apps for Mobile Me. The mandate was to recreate the experience of Mac apps like Mail and iCal, and that effort continues on Sproutcore today with iCloud.
Jolley left Apple and formed a company called Strobe in San Francisco with a vision in part to leverage Sproutcore. The team at Strobe decided that Sproutcore didn't fit many Web 2.0 use cases well enough, and was too much of an all-or-nothing proposition for developers, so they initiated an effort toward Sproutcore 2. The goals of Sproutcore 2 were modularity, and a more HTML-aware approach that would be more accessible to web developers everywhere. Backbone's early traction was part of this analysis.
After struggling to move the Sproutcore codebase toward this vision, the Strobe team decided to start fresh with Sproutcore 2 (internal codename Amber). Charles wrote the core Run Loop and key-value observer code. Yehuda Katz and Tom Dale were the lead Strobe developers on the project. The vision at the time was that Strobe and the community would eventually port over most features and functionality from Sproutcore 1.x to Sproutcore 2.
Strobe business efforts were not yielding hoped-for results, and the company weighed its options, eventually deciding on a acquisition of Strobe talent by Facebook. Before this happened, a number of Strobe employees, including Katz and Dale, split off to form a new company called Tilde.
Tilde decided to continue to develop Sproutcore 2, but change the name (to Amber.js and then Ember.js) and goals of the project. They dropped long-term goals of backward compatibility with Sproutcore. They dropped support for any kind of view widget library and focused on the HTML/CSS use case with tight integration of data binding with the Handlebars templating language.
Since the dissolution of Strobe, stewardship of Sproutcore 1.x has passed from Jolley to Tyler Keating, and the community has re-focused on cleaning up Sproutcore 1.x, which was in an uncomfortable place for a while when the idea of Sproutcore 2 was looming.
What are the effective differences between the two efforts?
The similarities in the projects are that they feature very similar object models. They have similar property, observer and binding systems, too.
Sproutcore includes a library of view widgets like toolbars, list views, grid views, buttons, and theming system, and a focus on defining the view layer via Javascript and absolute positioning managed by the library. It is very powerful for creating desktop-style apps on the web.
Ember has a smaller footprint. It features tight integration with Handlebars. It is an alternative to Backbone for many projects. It aims to provide a standard application architecture for client-side apps and eliminate boilerplate code.
Those differences will likely lead to the frameworks diverging, although there has been some consideration of adopting the same core. In that scenario, Sproutcore would use Ember's "metal" library and perhaps other core libs).
What is Sproutcore's future, where is it going now?
This thread has minutes from the a recent contributor's meetup.
https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#
The short-term roadmap is to focus on solidifying the marketing materials, demos, and codebase. The team recently released the Sproutcore Showcase. There is general consensus about replacing abbot, the Ruby build tools for Sproutcore, with a Javascript(node.js)-based solution, which is now under active development. There is also a desire for fewer "large" merges of code from companies like Apple and more frequent releases. Sproutcore 1.8 was recently released.
Is Ember going develop to be a complete replacement for sproutcore?
Not likely. The Ember core team has been clear that they have no intention of personally developing those missing features. It is possible that community members may develop those as separate projects -- flame.js is the most ambitious attempt so far. Ember's design choices make it easier to integrate with projects like jQuery UI, so a full replacement may or may not be necessary.
1) The official line is Sproutcore is intended for RIAs and Ember.js is intended for "web-styled" applications. So when you look at iCloud think Sproutcore and when you look at Twitter think Ember.js.
From the technical standpoint, Ember.js is focused on more modularized code and so called "semantic-templates" for views. Sproutcore is more monolithic.
2) I'm not sure anyone really knows. If you look at the timeline, Charles Jolley left Apple to form a company called Strobe, which developed a full-stack platform for application development. Strobe hired Yehuda Katz and others, who began working on slimming down SC so it would run better on mobile devices. After about a year, Yehuda left to form the company Tilde, and a month after that Facebook bought Strobe in what is widely regarded as a talent acquisition.
So interpret that as you will.
3) This is an excellent question. Recently there was a meetup and several things were discussed. Key points discussed were:
SC is still alive and kicking
Improve documentation (we have been hearing that for a while).
Keep the good parts the code that was introduced post 1.4.5 in development of SC2 and get rid of or move to optional modules other stuff (like Templates)
new javascript-based build tools
completely new canvas based view layer, called Blossom.
Some sort of foundation/corporate backing for SC
There are probably others that I missed
4) Definitely not a replacement, although you can use any framework to build any app (it's all javascript, after all).
Up to now I've always used PHP with or without a framework but a month ago I decided to start something new: Ruby and Rails, I found them quite easy and similar to PHP and some PHP frameworks in how they works but using a simpler syntax and many other advantages.
Some days ago I started reading about Node.js, Node.js vs Rails, "why node.js is better"...
I'm a bit confused but my objective is to learn something modern that will not become obsolete in a few months so:
What are the main differences between Rails/Ruby and Node.js and a framework based on it like Express.js (except that one is written in JS and the other in Ruby)?
What are the main advantages/disadvantages of using Node.js and framework based on it instead of a Ruby based solution like Rails?
Thanks!
There aren't enough differences between Node.js and Rails for it to practically matter.
A lot of what Node.js can do can be pulled off in Rails with things like EventMachine and Pusher. So unless you are really familiar with Rails' limitations, and know you'll be pushing the boundaries, you'd be hard pressed to make something a seasoned Rails developer couldn't do.
Having built apps in Node and Express I can say that they alone aren't enough to make a sexy application. They can seem just as old and stale if you don't have an outstanding frontend UI to facilitate the backend possibilities. Instead of comparing backend servers, I think the real future of doing amazing things is in front-end JavaScript frameworks like Backbone.js that use Express/Rails/Node.js on the backend.
I have chosen to go in the direction of Backbone.js with Rails as my backend API server. Because it's so easy to rapidly create a very nice RESTful backend server in Rails. Rails also makes working with CoffeeScript and precompiling/organizing Backbone code a breeze. There are already decent Backbone.js gems out there for Rails.
The Rails core is also able to acknowledge and embrace the fact that frontend JS MVCs are logically a good next step, and they have been working to strengthen the bond between the two. For those same reasons they have also worked to make Rails an even better API server so that it can work with frontend JS easier. Node.js and Express aren't putting as much effort to coordinate with frontend JavaScript MVCs as the Rails community is.
Being good with a JavaScript frontend MVC and Rails as a backend makes you also great for both worlds in terms of getting a job. You will easily be able to hop onto a Node.js project and add value to that team with your superior frontend experience, and you can also roll with the punches on a Ruby on Rails team and add value to them as well.
As official Node.js website explains it:
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
On the other hand Ruby on Rails official website says:
Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.
Given this I guess that it is more appropriate to compare Ruby and Node.js, but even this is not quite right given that Ruby is programming language and Node.js is NOT. You could probably compare JavaScript with Ruby but I guess that is not what you meant to ask with this question :)
So, for me, key point in understanding what Node.js truly tries to accomplish is well described on Node.js about page. Key Node.js idea (for me) is described in this sentences:
Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. In other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run(). In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser javascript—the event loop is hidden from the user.
What this should enable you, is that you should be able to easily write highly concurrent programs without even thinking about concurrency using JavaScript syntax and callback functions as basic concurrent runnable units.
Your fear that either Rails or Node.js will be gone in a week is unfounded. Rails has a large community and will be around for a very long time even though currently (early 2012) it's getting a bit of hate thrown its way. Node.js is just getting started and has so much attention I don't think it will have any problems getting to the Rails level some day.
That said I've been evaluating Node.js and Rails as options for a project and the reasons I choose Node.js over Rails are:
"The Rails Way" - In my (admittedly limited) experience with Rails it really seems like you either do it the Rails way or you are going to be in for a world of pain. A big part of the Rails way is to use the ActiveRecord model. The advantage of this is that there are a lot of gems that work with your code happily because they know you'll be using ActiveRecord. The disadvantage is you are mixing your data access & model. I am not a fan of this idea so the Rails way for me still seems a bit.. off.
JavaScript is a key part of client side web development and the idea of using it on the client and server is interesting. I'm not super strong at JavaScript and I can't imagine a better way to get better then to have to use it everywhere.
My project has real time communication needs which while I'm sure can be done in Rails there seems to be quite a bit of positive mention on Nodes ability to handle this with socket.io being the front runner option.
At the end of the day no matter which you choose you will have a great time & learn a ton of new stuff that will change how you write code. If you're not on a big time crunch I'd recommend building a small project management tool in both and see which you prefer.
Either way.. Good Luck!
2 things - performance & productivity.
Performance (more details here)
(source: jslang.info)
Productivity (how fast you can build that app)
Ruby on Rails is specialized and highly productive tool for creating so called Web 1.0 and Web 2.0 applications (99% of internet sites are such apps). In my subjective judgement and experience in this area Rails about 2-4 times more productive than node.js or express.js.
For Web 3.0 apps (realtime things, client-side MVC, etc.) this isn't true, RoR doesn't keep its advantage there.
So choice depends on use case and priorities.
I know a lot more about Node.js than I do about Ruby. That being said, Ruby is much more widely adopted. It is currently a very hot skill to have in the work place. Some may argue with me on this but I think that Node.js is still "under development" and will be for a little bit longer. It has a lot of promise but just hasn't been adopted by many companies and projects yet.
I'm going to develop a collaborative site, and one of the features will be collaborative editing with realtime changes. i.e. when two or more users are editing the same doc, they can see each other changes as soon as they happen.
I have some experience with Ruby on Rails, so I was thinking about using EventMachine, but with all this hype around Node.js, I am know considering using it instead. So, what would be the main benefits of using Node.js instead of EventMachine?
tl;dr
What are the main differences between EventMachine and Node.js (besides the language)?
EventMachine has nothing to do with Rails apart from them both being written in the same language. You can get EventMachine as bare as Node.js; all you have to do is not add libraries to your project. In my experience the EventMachine libraries (like em-http) are much nicer than anything for Node. And you can use fibers instead of callbacks to avoid callback hell. Complete exception handling is pretty much impossible in Node because of all the callbacks. Plus Ruby is a nicer, more complete language than Javascript.
I tend towards the "use what you know" (even if it's a heavier architecture). Because of that, I don't see it being quite as simple as "EventMachine vs NodeJS." Mainly, the difference can be summarized as this:
NodeJS is a framework/language that was written to handle event based programming in JavaScript. That is its driving force. It's not an after thought, or a third party mechanism. It's baked right in to the language. You create callbacks/events because that's how the language is built. It's not a third party plug in, and doesn't alter your workflow.
EventMachine is a gem in Ruby that gives developers access to some of the goodness of the event based programming model. It's heavily used and well tested, but not baked directly in to the language. Both are locked to one CPU, but with event programming at Nodes core, it still has a leg up. Ruby wasn't written with concurrency in mind.
That said, technical problems can be overcome. The more important questions (from my view) that should guide your decision are these:
What will your production environment look like? Do you have complete control over the server? Can you host it however you want? Or will it be on a shared system to start with, and then you have to expand on that?
Do all the developers on your team have the ability to learn a new language very fast? How fast will they be able to understand an event-based language like JavaScript for the middle tier?
Do you need all of the architecture that Rails gives you (full Testing framework, scaffolding, models, controllers, etc)? Or is that overkill?
There are quite a few technical differences between the two. One is a language, one is a framework. Really, how heavy of a stack you want to run? How much learning will your developers have to do? Do you want a full stack the gives you a lot of niceties, that you may not use, or do you want a bare bones set up that runs extremely fast and concurrent, even though you may have to write extra boiler plate code and learn a new lanugage?
While Rails is not as heavy as some web application architectures, you're still going to need more processor power than you would to handle a similar amount of throughput in NodeJS. Assuming quality code for both systems. Bad code written on either stack is going to prevent the stack from shining. It really comes down to- Do you really want to learn a whole new way of doing things, or utilize your current understanding of Ruby to get things off the ground fast?
I know it's not really a definitive answer, but I hope this helps guide you to a decision!
One thing worth mentioning is the production story. EM, like most Rack stuff, has plenty of testing and monitoring tools available that are well tested, whereas Node.js falls well short in this respect.
At the time of writing, it seems almost impossible to get clear metrics from Node to answer questions like 'Do I need to scale'. There are options starting to form out there from the likes of Joyent, and always the roll-your-own argument, but nothing anywhere near tools such as NewRelic.
Node.js is very good from a performance / configurability point of view, but personally I wouldn't host it in production just yet.
Node.js
You get far better control low level control over what's going in. You can include general libraries to build on top of node.js to tweak your level of abstraction to your own liking. For example you can use connect or express depending on whether you want a view engine written for you.
You can use socket.io or now depending on how much you want your client-server connection abstracted. You can opt to include any of numerous MVC libraries or write your own.
Event-Machine
An asynchronous IO library just like node.js
It comes down to a Ruby vs JavaScript preference, how much flexibility you want with abstractions or lack of abstractions and whether you want to use node as your actual web server.
a detailed view at confusion has already been proposed... just a personal view
[] node.js will be better, if you are ready to learn and experiment more than you think because:
it's thread mechanism is awesome (inspired from that of 'erlang')
you can build a purpose specific server (easily) which will be real productive
So I've been tasked at work to write windows services to replace some old legacy VB6 WinForms apps currently running as services, consistently repeating tasks day-to-day. To give some general background, they have there own state machines built in to handle decision basing and not utilizing threading.
A lot of the senior developers here thought it would be worth a try to look into WorkFlow to replace the state machines rather than write my own business logic and try threading it programmaticly. So it's WF vs. the "Old College Try" I suppose.
My concern is that there aren't many books on the topic, and since it was implemented in .Net I've heard very little about it being used. I brought this up at work and another developer mentioned that it's because Biz Talk never really caught on and it was designed for that.
So is it broken? Do you think it will be supported long enough to not worry so much? I don't want an ill-functioning process injected into my services, my new babies at work, and then have WF's keel over. Leaving me with having to replace them with my own code in the event of an emergency; which does not seem like much of a grand scenario to me.
Any suggestions, recommendations would be super.
Workflow Foundation is used in Microsoft SharePoint, so I think they will continue supporting it.
There is an open source project called Stateless by Nicholas Blumhardt. It is quite flexible and very light weight. See my SO answer for details.
I chose this over Windows Workflow simply because I could define a state as State and thereby persist the state of my workflows back to the database using SubSonic. Configuration consists of one XML file. If I need to add tasks, I simply add nodes to the XML.
The each state can have a series of triggers that once satisfied will advance to appropriate state. This framework is a single assemble and fits nicely in your domain logic.
I have a memory of talking to people who have got so far in using Ruby on Rails and then had to abandon it when they have hit limits, or found it was ultimately too rigid. I forget the details but it may have had to do with using more than one database.
So what I'd like is to know is what features/requirements fall outside of Ruby on Rails, or at least requires such contortions that it is better to use another more flexible framework, even though you may have to lose some elegance or write extra boilerplate code.
Rails (not ruby itself) is proud to be "Opinionated Software".
What this means in practice is that the authors of rails have a certain target audience in mind (themselves basically) and aim rails specifically at that. If X feature isn't needed for that target audience, it doesn't get added.
Off the top of my head, things that rails explicitly doesn't support that people may care about:
Foreign keys in databases
Connections to multiple DB's at once
SOAP web services (since rails 2.0)
Connections to multiple database servers at once
That said, it is very easy to extend rails with plugins, and there are plugins which add all of the above functionality to rails, and a lot more, so I wouldn't really count these as limits.
The only other caveat is that rails is built around the idea of creating CRUD web applications using MVC. If you're trying to do something which is NOT a CRUD web app (like twitter, which is actually a messaging system, or if you are insane and want to use a model like ASP.NET webforms) then you will also encounter problems. In this case you're better off not using rails, as you're essentially trying to build a boat out of bicycle parts.
In all likelihood, the problems you will run into that can't just be fixed with a quick plugin or a day or 2 of coding are all inherent problems with the underlying C Ruby runtime (memory leaks, green threads, crap performance, etc).
Ruby on Rails does not support two-phase commits out of the box, which maybe required if your database-backed application needs to guarantee immediate consistency AND you need to use two or more database schemas.
For many web applications, I would venture that this is not a common use-case. One can perfectly well support eventual consistency with two or more databases. Or one could support immediate consistency with one database schema. The former case is a great problem to have if your app has to support a mondo amount of transactions (note the technical term :). The latter case is more typical, and Rails does just fine.
Frankly, I wouldn't worry about limits to using Ruby on Rails (or any framework) until you hit real scalability problems. Build a killer app first, and then worry about scalability.
CLARIFICATION: I'm thinking of things that Rails would have a hard-time supporting because it might require a fundamental shift in its architecture. I'll be generous and include some things that are part of the gem/plugin ecosystem such as foreign key enforcement or SOAP services.
By two-phase commits, I mean attempting to make two commits to physically distinct servers within one transactional context.
Use case #1 for a two-phase commit: you've clustered your database, so that you have 2 or more database servers and your schema is spread across both servers. You may want to commit to both servers, because you want to allow ActiveRecord think do a "foreign key map" that traverses across the different servers.
Use case #2 for a two-phase commit: you're attempting to implement a messaging solution (sorry, I'm J2EE developer by day). The message producer commits to the messaging broker (one server) and to the database (a different server).
Also found some good discussion about the limits of ActiveRecord.
I think there is a greater “meta-question” here, that could be answered and that is “when is it OK to lean on external libraries to speed up development time?”
Third party libraries are often great and can drastically reduce development time, however there is a major problem, Joel Spolsky calls this “the law of leaky abstractions.” If you look that up on Google his post will come up first. Essentially this means that the trade off in development time means that you have no idea what is going on under the covers. So when something breaks you are completely stuck and have very limited methods of debugging. This also means that if you hit one of the features that are simply unsupported in RAILS, that you really need, you’ll have no next step except to write the feature yourself, if you’re lucky. Many libraries can make this difficult to do.
We’ve been burned badly in my dev shop by this issue. Our solutions worked fine under normal load, but we found that the third party subscription libraries that we were using simply could not stand up to the kind of load that we experienced once our site started to get a large number of concurrent users. This puts us in a very difficult place; essentially we have to rewrite the entire subscription service ourselves, with performance in mind. Doing this means that we’ve wasted all the time that we spent using the library.
Third party libraries can be great for small to medium sized applications; they can drastically reduce development time and hide complexities that aren’t necessary to deal with in the early stages of development. However eventually they will catch up with you and you’ll likely have to rewrite or re-engineer your solution to get past the “law of leaky absctractions”
Ruby don't have a functionality like IsPostBack in ASP.Net
Orion's answer is right on. There are few hard limits to AR/Rails: deploying to Windows, AR connectors that aren't frequently used, e.g. Firebird, ), but even the things he mentioned, multiple databases and DB servers, there are gems and plugins that address those for legacy, sharding, and other reasons.
The real limitation is how time-consuming it is to keep on top of all the things that rails devs are working on, and researching specific issues, given how many blogs, and how much mailing list volume there are.