Alternatives to Payara logo

Alternatives to Payara

GlassFish, Wildfly, Jetty, nginx, and Apache HTTP Server are the most popular alternatives and competitors to Payara.
15
13
+ 1
0

What is Payara and what are its top alternatives?

It Server is a drop in replacement for GlassFish Server Open Source Edition with quarterly releases containing enhancements, bug fixes and patches.
Payara is a tool in the Web Servers category of a tech stack.
Payara is an open source tool with 731 GitHub stars and 229 GitHub forks. Here’s a link to Payara's open source repository on GitHub

Payara alternatives & related posts

GlassFish logo

GlassFish

39
26
0
39
26
+ 1
0
The Open Source Java EE Reference Implementation
    Be the first to leave a pro
    GlassFish logo
    GlassFish
    VS
    Payara logo
    Payara
    Wildfly logo

    Wildfly

    79
    35
    2
    79
    35
    + 1
    2
    A Java EE8 Application Server
    Wildfly logo
    Wildfly
    VS
    Payara logo
    Payara
    Jetty logo

    Jetty

    312
    151
    41
    312
    151
    + 1
    41
    An open-source project providing an HTTP server, HTTP client, and javax.servlet container
    Jetty logo
    Jetty
    VS
    Payara logo
    Payara
    nginx logo

    nginx

    57.6K
    15.9K
    5.4K
    57.6K
    15.9K
    + 1
    5.4K
    A high performance free open source web server powering busiest sites on the Internet.
    nginx logo
    nginx
    VS
    Payara logo
    Payara

    related nginx posts

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

    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.

    See more
    Node.js
    Node.js
    Ubuntu
    Ubuntu
    MySQL
    MySQL
    npm
    npm
    Framework7
    Framework7
    Vue.js
    Vue.js
    Webpack
    Webpack
    nginx
    nginx
    #Lenovo
    #HapiJS
    #Framework7
    #Plaid

    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.

    See more

    related Apache HTTP Server posts

    Tim Abbott
    Tim Abbott
    Founder at Zulip · | 7 upvotes · 93.3K views
    atZulipZulip
    nginx
    nginx
    Apache HTTP Server
    Apache HTTP Server

    We've been happy with nginx as part of our stack. As an open source web application that folks install on-premise, the configuration system for the webserver is pretty important to us. I have a few complaints (e.g. the configuration syntax for conditionals is a pain), but overall we've found it pretty easy to build a configurable set of options (see link) for how to run Zulip on nginx, both directly and with a remote reverse proxy in front of it, with a minimum of code duplication.

    Certainly I've been a lot happier with it than I was working with Apache HTTP Server in past projects.

    See more
    Marcel Kornegoor
    Marcel Kornegoor
    CTO at AT Computing · | 7 upvotes · 68K views
    nginx
    nginx
    Apache HTTP Server
    Apache HTTP Server

    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.

    See more
    Apache Tomcat logo

    Apache Tomcat

    5.4K
    3.4K
    195
    5.4K
    3.4K
    + 1
    195
    An open source software implementation of the Java Servlet and JavaServer Pages technologies
    Apache Tomcat logo
    Apache Tomcat
    VS
    Payara logo
    Payara

    related Apache Tomcat posts

    Java
    Java
    Spring
    Spring
    JUnit
    JUnit
    Apache HTTP Server
    Apache HTTP Server
    Apache Tomcat
    Apache Tomcat
    MySQL
    MySQL

    Java Spring JUnit

    Apache HTTP Server Apache Tomcat

    MySQL

    See more
    OpenResty logo

    OpenResty

    2.1K
    86
    0
    2.1K
    86
    + 1
    0
    Turning Nginx into a Full-fledged Web App Server
      Be the first to leave a pro
      OpenResty logo
      OpenResty
      VS
      Payara logo
      Payara

      related OpenResty posts

      Chris McFadden
      Chris McFadden
      VP, Engineering at SparkPost · | 7 upvotes · 135.9K views
      atSparkPostSparkPost
      nginx
      nginx
      OpenResty
      OpenResty
      Lua
      Lua

      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?

      See more
      Prometheus
      Prometheus
      Logstash
      Logstash
      nginx
      nginx
      OpenResty
      OpenResty
      Lua
      Lua
      Go
      Go

      At Kong while building an internal tool, we struggled to route metrics to Prometheus and logs to Logstash without incurring too much latency in our metrics collection.

      We replaced nginx with OpenResty on the edge of our tool which allowed us to use the lua-nginx-module to run Lua code that captures metrics and records telemetry data during every request’s log phase. Our code then pushes the metrics to a local aggregator process (written in Go) which in turn exposes them in Prometheus Exposition Format for consumption by Prometheus. This solution reduced the number of components we needed to maintain and is fast thanks to NGINX and LuaJIT.

      See more
      LiteSpeed logo

      LiteSpeed

      1.8K
      11
      0
      1.8K
      11
      + 1
      0
      A drop-in Apache replacement and the leading high-performance, high-scalability server
        Be the first to leave a pro
        LiteSpeed logo
        LiteSpeed
        VS
        Payara logo
        Payara
        Gunicorn logo

        Gunicorn

        643
        320
        62
        643
        320
        + 1
        62
        A Python WSGI HTTP Server for UNIX
        Gunicorn logo
        Gunicorn
        VS
        Payara logo
        Payara

        related Gunicorn posts

        Gunicorn
        Gunicorn
        uWSGI
        uWSGI
        Heroku
        Heroku
        AWS Elastic Beanstalk
        AWS Elastic Beanstalk

        I use Gunicorn because does one thing - it’s a WSGI HTTP server - and it does it well. Deploy it quickly and easily, and let the rest of your stack do what the rest of your stack does well, wherever that may be.

        uWSGI “aims at developing a full stack for building hosting services” - if that’s a thing you need then ok, but I like the principle of doing one thing well, and I deploy to platforms like Heroku and AWS Elastic Beanstalk where the rest of the “hosting service” is provided and managed for me.

        See more
        Cowboy logo

        Cowboy

        584
        26
        15
        584
        26
        + 1
        15
        Small, fast, modular HTTP server written in Erlang.
        Cowboy logo
        Cowboy
        VS
        Payara logo
        Payara
        Unicorn logo

        Unicorn

        481
        303
        295
        481
        303
        + 1
        295
        Rack HTTP server for fast clients and Unix
        Unicorn logo
        Unicorn
        VS
        Payara logo
        Payara

        related Unicorn posts

        Simon Bettison
        Simon Bettison
        Managing Director at Bettison.org Limited · | 7 upvotes · 144.8K views
        atBettison.org LimitedBettison.org Limited
        PostgreSQL
        PostgreSQL
        Elasticsearch
        Elasticsearch
        Sidekiq
        Sidekiq
        Redis
        Redis
        Amazon ElastiCache
        Amazon ElastiCache
        Rails
        Rails
        RSpec
        RSpec
        Selenium
        Selenium
        Travis CI
        Travis CI
        Ruby
        Ruby
        Unicorn
        Unicorn
        nginx
        nginx
        Amazon CloudFront
        Amazon CloudFront
        Amazon SES
        Amazon SES
        Amazon SQS
        Amazon SQS
        Amazon Route 53
        Amazon Route 53
        Amazon VPC
        Amazon VPC
        Docker
        Docker
        Amazon EC2 Container Service
        Amazon EC2 Container Service

        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

        See more
        Jerome Dalbert
        Jerome Dalbert
        Senior Backend Engineer at StackShare · | 6 upvotes · 99.8K views
        atStackShareStackShare
        Unicorn
        Unicorn
        Puma
        Puma
        Rails
        Rails

        We switched from Unicorn (process model) to Puma (threaded model) to decrease the memory footprint of our Rails production web server. Memory indeed dropped from 6GB to only 1GB!

        We just had to decrease our worker count and increase our thread count instead. Performance (response time and throughput) remained the same, if not slightly better. We had no thread-safety errors, which was good.

        Free bonus points are:

        • Requests are blazing fast on our dev and staging environments!
        • Puma has first-class support for WebSockets, so we know for sure that Rails ActionCable or GraphQL subscriptions will work great.
        • Being on Puma makes us even more "default Rails"-compliant since it is the default Rails web server these days.
        See more
        Puma logo

        Puma

        263
        148
        16
        263
        148
        + 1
        16
        A Modern, Concurrent Web Server for Ruby
        Puma logo
        Puma
        VS
        Payara logo
        Payara

        related Puma posts

        Jerome Dalbert
        Jerome Dalbert
        Senior Backend Engineer at StackShare · | 6 upvotes · 99.8K views
        atStackShareStackShare
        Unicorn
        Unicorn
        Puma
        Puma
        Rails
        Rails

        We switched from Unicorn (process model) to Puma (threaded model) to decrease the memory footprint of our Rails production web server. Memory indeed dropped from 6GB to only 1GB!

        We just had to decrease our worker count and increase our thread count instead. Performance (response time and throughput) remained the same, if not slightly better. We had no thread-safety errors, which was good.

        Free bonus points are:

        • Requests are blazing fast on our dev and staging environments!
        • Puma has first-class support for WebSockets, so we know for sure that Rails ActionCable or GraphQL subscriptions will work great.
        • Being on Puma makes us even more "default Rails"-compliant since it is the default Rails web server these days.
        See more
        Caddy logo

        Caddy

        127
        53
        7
        127
        53
        + 1
        7
        The HTTP/2 Web Server with Automatic HTTPS
        Caddy logo
        Caddy
        VS
        Payara logo
        Payara

        related Caddy posts