nginx

nginx

Application and Data / Application Hosting / Web Servers

Decision at Raygun about AWS Elastic Load Balancing (ELB), Amazon EC2, nginx, Amazon RDS, Amazon S3, LoadBalancerReverseProxy, CloudStorage, WebServers, CloudHosting

Avatar of CmdrKeen
Co-founder & CEO at Raygun ·
AWS Elastic Load Balancing (ELB)AWS Elastic Load Balancing (ELB)Amazon EC2Amazon EC2nginxnginxAmazon RDSAmazon RDSAmazon S3Amazon S3
#LoadBalancerReverseProxy
#CloudStorage
#WebServers
#CloudHosting

We chose AWS because, at the time, it was really the only cloud provider to choose from.

We tend to use their basic building blocks (EC2, ELB, Amazon S3, Amazon RDS) rather than vendor specific components like databases and queuing. We deliberately decided to do this to ensure we could provide multi-cloud support or potentially move to another cloud provider if the offering was better for our customers.

We’ve utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an nginx instance and are managed using scaling groups in Amazon EC2 sitting behind a standard AWS Elastic Load Balancing (ELB).

While we’re satisfied with AWS, we do review our decision each year and have looked at Azure and Google Cloud offerings.

#CloudHosting #WebServers #CloudStorage #LoadBalancerReverseProxy

19 upvotes·24.6K views

Decision about GitHub, nginx, ESLint, AVA, Semantic UI React, Redux, React, PostgreSQL, ExpressJS, Node.js, FeathersJS, Heroku, Amazon EC2, Kubernetes, Jenkins, Docker Compose, Docker, Frontend, Stack, Backend, Containers, Containerized

Avatar of jordandenison

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

15 upvotes·63K views

Decision about PHP, Bulma, Asana, Stripe, Let's Encrypt, CloudFlare, Deployer, Git, GitHub, Ubuntu, nginx, Buddy, Webpack, Vue.js, JavaScript, HTML5, Sass, Google Analytics, PhpStorm, Laravel, CDG

Avatar of Epistol
Epistol.fr ·
CDG

I use Laravel because it's the most advances PHP framework out there, easy to maintain, easy to upgrade and most of all : easy to get a handle on, and to follow every new technology ! PhpStorm is our main software to code, as of simplicity and full range of tools for a modern application.

Google Analytics Analytics of course for a tailored analytics, Bulma as an innovative CSS framework, coupled with our Sass (Scss) pre-processor.

As of more basic stuff, we use HTML5, JavaScript (but with Vue.js too) and Webpack to handle the generation of all this.

To deploy, we set up Buddy to easily send the updates on our nginx / Ubuntu server, where it will connect to our GitHub Git private repository, pull and do all the operations needed with Deployer .

CloudFlare ensure the rapidity of distribution of our content, and Let's Encrypt the https certificate that is more than necessary when we'll want to sell some products with our Stripe api calls.

Asana is here to let us list all the functionalities, possibilities and ideas we want to implement.

11 upvotes·67.3K views

Decision at SparkPost about Lua, OpenResty, nginx

Avatar of cristoirmac
VP, Engineering at SparkPost ·

We use nginx and OpenResty as our API proxy running on EC2 for auth, caching, and some rate limiting for our dozens of microservices. Since OpenResty support embedded Lua we were able to write a custom access module that calls out to our authentication service with the resource, method, and access token. If that succeeds then critical account info is passed down to the underlying microservice. This proxy approach keeps all authentication and authorization in one place and provides a unified CX for our API users. Nginx is fast and cheap to run though we are always exploring alternatives that are also economical. What do you use?

7 upvotes·21.9K views

Decision about nginx, Webpack, Vue.js, Framework7, npm, MySQL, Ubuntu, Node.js, Plaid, Framework7, HapiJS, Lenovo

Avatar of mbplautz

I just designed, developed, and deployed my own budgeting app, dailybudget.cc, which allows me to automate my budgeting the way I have always done it, in a way that I could never fully capture with other budgeting apps, such as Mint, EveryDollar, or YNAB. I spent 4 years from the time I first had the idea to the time I actually sat down to design it and start development. During this time I evaluated many other budgeting app solutions, and had even architected a prototype that I never ended up using. But boy, have technologies come much further in 4 years.

Though my first prototype used Java and Tomcat, I completely abandoned those 4 years later in favor of Node.js technologies, which I have found are equally as stable, more flexible (for better or for worse), and capable of significantly more rapid development. Since what I have deployed now is in beta and is primarily for limited user use, I favored rapid development over slower development where I would write more automated unit tests. I chose to build the app as a HTML5 web application (rather than native iOS or Android, for now), and I used a separated API backend/Web frontend model. My target platform for use with the app is mobile handheld touch devices, though it can work on any laptop or desktop with a touchscreen. Given these design targets, many of the technologies I chose were because of familiarity with them as well as a strong online community, and some technologies I chose that I had to learn anew, because they appeared to fit my needs.

My entire app runs on a #lenovo IdeaCentre desktop on my home network, on which I have installed Ubuntu 18.04. Ubuntu is something I have switched to after a long time of use and familiarity with RedHat Enterprise Linux and CentOS, because the online support for Ubuntu is now tremendous, and there is so much documentation and examples online of how to configure and use Ubuntu; not to mention I have not been thrilled with the direction new releases of CentOS. Ubuntu is also a good environment for development - it is so easy to follow the many online examples. Lastly, I may migrate my app and configuration to Amazon AWS, which also uses Ubuntu for its EC2 Linux VMs, so having Ubuntu now is helpful for that prospect.

The API backend uses Node.js, with #HapiJS as the API server framework and MySQL as my persistence database. HapiJS is something I have had familiarity with and is just a phenomenal framework to plug into and configure, especially if you use it for a route-based API. #Mysql has a great online community. I could've used PostgreSQL too, but I am more familiar with MySQL. Also, if I migrate to Amazon AWS, Amazon's RDS uses MySQL. I use npm as a one-stop-shop package manager and environment manager.

The Web frontend uses a combination of Framework7 and Vue.js. I cannot evangelize Framework7 enough! It is a fantasic tool by @nolimits4web (GitHub) that is really easy to use, really well thought out, and really performant. Framework7 simulates the native iOS or Android (Google Material) experiences, all using HTML5 constructs (HTML+CSS+JS). Vue.js is another very fantastic binding and frontend framework which has a good online community and is well documented and easy to use. I had to choose between VueJS and ReactJS, and ultimately chose VueJS over ReactJS because it seemed to favor more rapid development with less ramp-up time, whereas I understood ReactJS to be more of an enterprise level framework (though still good for smaller projects like mine). When using Framework7 with VueJS, NodeJS is used along with Webpack to transpile my code into browser-friendly JavaScript, HTML, etc. Webpack was nice to use because it has a hot-deploy development mode to enable rapid development without me having stop, recompile, and start my server (this was one of several reasons against using Java with Tomcat). I had no familiarity with Framework7, VueJS, or Webpack prior to this project.

I use nginx as my web server and have the API running behind a reverse proxy, and all of the web frontent content hosted as static content.

I use the plaid API to sync my bank transactions to my database. This is another fantastic framework (though not free beyond development use) that it turns out is extremely easy to use for the complex job that it solves.

7 upvotes·2 comments·18K views

Decision at Bettison.org Limited about Amazon EC2 Container Service, Docker, Amazon VPC, Amazon Route 53, Amazon SQS, Amazon SES, Amazon CloudFront, nginx, Unicorn, Ruby, Travis CI, Selenium, RSpec, Rails, Amazon ElastiCache, Redis, Sidekiq, Elasticsearch, PostgreSQL

Avatar of sgbett
Managing Director at Bettison.org Limited ·

In 2010 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.

Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.

PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.

Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!

Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.

We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).

Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service

6 upvotes·39.3K views

Decision about .NET Core, .NET, Linux, nginx, MariaDB, GitLab, Git, Visual Studio

Avatar of qaerdogan
Developer at Prizma ·

Visual Studio Git GitLab MariaDB nginx Linux

Visual Studio 2019 is increasing my productivity incredibly when I building MVC WebAPI and Web project. GitLab is essential tools for me. Issue boards are great as well as Source code safe in GitLab. The most amazing thing is Microsoft's new strategy on .NET enviroment for me. I love .NET Core 's cross platform support. I can deploy my projects on Linux via nginx and .NET Core runtime or self host options. MariaDB become our first choose database option because of its great talents.

6 upvotes·6.4K views

Decision about Apache HTTP Server, nginx

Avatar of mckornegoor
CTO at AT Computing ·

nginx or Apache HTTP Server that's the question. The best choice depends on what it needs to serve. In general, Nginx performs better with static content, where Apache and Nginx score roughly the same when it comes to dynamic content. Since most webpages and web-applications use both static and dynamic content, a combination of both platforms may be the best solution.

Since both webservers are easy to deploy and free to use, setting up a performance or feature comparison test is no big deal. This way you can see what solutions suits your application or content best. Don't forget to look at other aspects, like security, back-end compatibility (easy of integration) and manageability, as well.

A reasonably good comparison between the two can be found in the link below.

6 upvotes·1 comment·1.8K views

Decision about Caddy, nginx

Avatar of smebberson
CTO / Chief Architect at Idearium ·

We used to primarily use nginx for our static web server and proxy in-front of Node.js. Now, we use Caddy. And we couldn't be happier.

Caddy is simpler on all fronts. Configuration is easier. Free HTTPS out of the box. Some fantastic plugins. And for the most part, it's fast.

Don't get me wrong, it's not lost on me that Nginx is actually a superior product.

But for the times when you don't need that extra performance, and complexity - take a look at Caddy.

5 upvotes·10.5K views

Decision at Mixmax about AWS Elastic Beanstalk, AWS Elastic Load Balancing (ELB), nginx, Go, Amazon EC2, Node.js, Meteor, Mixmax

Avatar of ttacon

As Mixmax began to scale super quickly, with more and more customers joining the platform, we started to see that the Meteor app was still having a lot of trouble scaling due to how it tried to provide its reactivity layer. To be honest, this led to a brutal summer of playing Galaxy container whack-a-mole as containers would saturate their CPU and become unresponsive. I’ll never forget hacking away at building a new microservice to relieve the load on the system so that we’d stop getting paged every 30-40 minutes. Luckily, we’ve never had to do that again! After stabilizing the system, we had to build out two more microservices to provide the necessary reactivity and authentication layers as we rebuilt our Meteor app from the ground up in Node.js. This also had the added benefit of being able to deploy the entire application in the same AWS VPCs. Thankfully, AWS had also released their ALB product so that we didn’t have to build and maintain our own websocket layer in Amazon EC2. All of our microservices, except for one special Go one, are now in Node with an nginx frontend on each instance, all behind AWS Elastic Load Balancing (ELB) or ALBs running in AWS Elastic Beanstalk.

5 upvotes·4.8K views