nginx vs Yesod: What are the differences?
Developers describe nginx as "A high performance free open source web server powering busiest sites on the Internet". nginx [engine x] is an HTTP and reverse proxy server, as well as a mail proxy server, written by Igor Sysoev. According to Netcraft nginx served or proxied 30.46% of the top million busiest sites in Jan 2018. On the other hand, Yesod is detailed as "A RESTful Haskell web framework built on WAI". Yesod believes in the philosophy of making the compiler your ally, not your enemy. We use the type system to enforce as much as possible, from generating proper links, to avoiding XSS attacks, to dealing with character encoding issues. In general, if your code compiles, it works. And instead of declaring types everywhere you let the compiler figure them out for you with type inference.
nginx can be classified as a tool in the "Web Servers" category, while Yesod is grouped under "Frameworks (Full Stack)".
"High-performance http server" is the primary reason why developers consider nginx over the competitors, whereas "Haskell" was stated as the key factor in picking Yesod.
nginx and Yesod are both open source tools. It seems that nginx with 9.11K GitHub stars and 3.44K forks on GitHub has more adoption than Yesod with 2.11K GitHub stars and 329 GitHub forks.
Airbnb, Uber Technologies, and Spotify are some of the popular companies that use nginx, whereas Yesod is used by DoxIQ, FP Complete, and SimplyRETS. nginx has a broader approval, being mentioned in 8677 company stacks & 2561 developers stacks; compared to Yesod, which is listed in 5 company stacks and 5 developer stacks.
What is nginx?
What is Yesod?
Want advice about which of these to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using nginx?
What are the cons of using Yesod?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
The original API performed a synchronous Nginx reload after provisioning a zone, which often took up to 30 seconds or longer. While important, this step shouldn’t block the response to the user (or API) that a new zone has been created, or block subsequent requests to adjust the zone. With the new API, an independent worker reloads Nginx configurations based on zone modifications.It’s like ordering a product online: don’t pause the purchase process until the product’s been shipped. Say the order has been created, and you can still cancel or modify shipping information. Meanwhile, the remaining steps are being handled behind the scenes. In our case, the zone provision happens instantly, and you can see the result in your control panel or API. Behind the scenes, the zone will be serving traffic within a minute.
Nginx serves as the loadbalancer, router and SSL terminator of cloudcraft.co. As one of our app server nodes is spun up, an Ansible orchestration script adds the new node dynamically to the nginx loadbalancer config which is then reloaded for a zero downtime seamless rolling deployment. By putting nginx in front or whatever web and API servers you might have, you gain a ton of flexibility. While previously I've cobbled together HAProxy and Stun as a poor man's loadbalancer, nginx just does a much better job and is far simpler in the long run.
Used nginx as exactly what it is great for: serving static content in a cache-friendly, load balanced manner.
It is exclusively for production web page hosting, we don't use nginx internally, only on the public-facing versions of static sites / Angular & Backbone/Marionette applications.
We use NGINX both as reverse HTTP proxy and also as a SMTP proxy, to handle incoming email.
We previously handled incoming email with Mandrill, and then later with AWS SES. Handling incoming email yourself is not that much more difficult and saves quite a bit on operational costs.