Alternatives to MongoDB Stitch logo

Alternatives to MongoDB Stitch

Firebase, Atlas, MongoDB Atlas, AWS Lambda, and GraphQL are the most popular alternatives and competitors to MongoDB Stitch.
133
231
+ 1
4

What is MongoDB Stitch and what are its top alternatives?

MongoDB Stitch is a serverless application platform that enables developers to build secure, scalable, and feature-rich applications. It offers features such as database triggers, authentication, serverless functions, and integrations with other services. However, some limitations of MongoDB Stitch include limited programming language support, constraints on customization, and potential cost barriers for high usage.

  1. Firebase: Firebase is a popular mobile application development platform acquired by Google. It offers features like real-time database, authentication, cloud functions, and hosting. Pros: Integration with Google services, real-time data sync. Cons: Limited querying capabilities, tied to Google ecosystem.
  2. AWS Lambda: AWS Lambda is a serverless computing service from Amazon Web Services. It allows you to run code without provisioning or managing servers. Pros: Integration with other AWS services, auto-scaling. Cons: May have complex pricing structure, less user-friendly for beginners.
  3. Azure Functions: Azure Functions is a serverless compute service that enables you to run event-triggered code without managing infrastructure. Pros: Tight integration with Azure services, multiple language support. Cons: Learning curve for beginners, potential vendor lock-in.
  4. Google Cloud Functions: Google Cloud Functions is a serverless environment to build and connect cloud services. Pros: Integration with Google Cloud Platform, multiple language support. Cons: Limited debugging capabilities, potential cost issues for high usage.
  5. Netlify Functions: Netlify Functions is a serverless platform that allows you to run server-side JavaScript functions without managing servers. Pros: Seamless integration with Netlify hosting, rapid deployment. Cons: Limited to JavaScript ecosystem, less flexibility compared to full serverless platforms.
  6. Heroku: Heroku is a cloud platform that enables developers to build, deliver, monitor, and scale applications. Pros: Easy to use, supports various programming languages. Cons: Limited free tier resources, potential scalability challenges.
  7. Twilio Functions: Twilio Functions is a serverless environment to run Twilio’s SDK. Pros: Tight integration with Twilio services, ability to build communication applications. Cons: Limited use cases beyond Twilio services, potential cost concerns for high usage.
  8. Vercel Functions: Vercel Functions is a serverless platform for hosting JavaScript functions in the cloud. Pros: Seamless integration with Vercel hosting, rapid deployment. Cons: Limited to JavaScript ecosystem, less flexibility compared to full serverless platforms.
  9. IBM Cloud Functions: IBM Cloud Functions is a serverless platform based on Apache OpenWhisk. Pros: Integration with IBM Cloud services, multiple language support. Cons: Complexity in setting up, potential performance issues with large workloads.
  10. Oracle Functions: Oracle Functions is a serverless platform built on top of Oracle Cloud Infrastructure. Pros: Integration with Oracle services, multiple language support. Cons: Limited in popularity and community support, potential challenges in customization.

Top Alternatives to MongoDB Stitch

  • Firebase
    Firebase

    Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds. ...

  • Atlas
    Atlas

    Atlas is one foundation to manage and provide visibility to your servers, containers, VMs, configuration management, service discovery, and additional operations services. ...

  • MongoDB Atlas
    MongoDB Atlas

    MongoDB Atlas is a global cloud database service built and run by the team behind MongoDB. Enjoy the flexibility and scalability of a document database, with the ease and automation of a fully managed service on your preferred cloud. ...

  • AWS Lambda
    AWS Lambda

    AWS Lambda is a compute service that runs your code in response to events and automatically manages the underlying compute resources for you. You can use AWS Lambda to extend other AWS services with custom logic, or create your own back-end services that operate at AWS scale, performance, and security. ...

  • GraphQL
    GraphQL

    GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012. ...

  • NGINX
    NGINX

    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. ...

  • Apache HTTP Server
    Apache HTTP Server

    The Apache HTTP Server is a powerful and flexible HTTP/1.1 compliant web server. Originally designed as a replacement for the NCSA HTTP Server, it has grown to be the most popular web server on the Internet. ...

  • Amazon EC2
    Amazon EC2

    It is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. ...

MongoDB Stitch alternatives & related posts

Firebase logo

Firebase

41.3K
2K
The Realtime App Platform
41.3K
2K
PROS OF FIREBASE
  • 371
    Realtime backend made easy
  • 270
    Fast and responsive
  • 242
    Easy setup
  • 215
    Real-time
  • 191
    JSON
  • 134
    Free
  • 128
    Backed by google
  • 83
    Angular adaptor
  • 68
    Reliable
  • 36
    Great customer support
  • 32
    Great documentation
  • 25
    Real-time synchronization
  • 21
    Mobile friendly
  • 19
    Rapid prototyping
  • 14
    Great security
  • 12
    Automatic scaling
  • 11
    Freakingly awesome
  • 8
    Super fast development
  • 8
    Angularfire is an amazing addition!
  • 8
    Chat
  • 6
    Firebase hosting
  • 6
    Built in user auth/oauth
  • 6
    Awesome next-gen backend
  • 6
    Ios adaptor
  • 4
    Speed of light
  • 4
    Very easy to use
  • 3
    Great
  • 3
    It's made development super fast
  • 3
    Brilliant for startups
  • 2
    Free hosting
  • 2
    Cloud functions
  • 2
    JS Offline and Sync suport
  • 2
    Low battery consumption
  • 2
    .net
  • 2
    The concurrent updates create a great experience
  • 2
    Push notification
  • 2
    I can quickly create static web apps with no backend
  • 2
    Great all-round functionality
  • 2
    Free authentication solution
  • 1
    Easy Reactjs integration
  • 1
    Google's support
  • 1
    Free SSL
  • 1
    CDN & cache out of the box
  • 1
    Easy to use
  • 1
    Large
  • 1
    Faster workflow
  • 1
    Serverless
  • 1
    Good Free Limits
  • 1
    Simple and easy
CONS OF FIREBASE
  • 31
    Can become expensive
  • 16
    No open source, you depend on external company
  • 15
    Scalability is not infinite
  • 9
    Not Flexible Enough
  • 7
    Cant filter queries
  • 3
    Very unstable server
  • 3
    No Relational Data
  • 2
    Too many errors
  • 2
    No offline sync

related Firebase posts

Stephen Gheysens
Lead Solutions Engineer at Inscribe · | 14 upvotes · 1.8M views

Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

See more
Eugene Cheah

For inboxkitten.com, an opensource disposable email service;

We migrated our serverless workload from Cloud Functions for Firebase to CloudFlare workers, taking advantage of the lower cost and faster-performing edge computing of Cloudflare network. Made possible due to our extremely low CPU and RAM overhead of our serverless functions.

If I were to summarize the limitation of Cloudflare (as oppose to firebase/gcp functions), it would be ...

  1. <5ms CPU time limit
  2. Incompatible with express.js
  3. one script limitation per domain

Limitations our workload is able to conform with (YMMV)

For hosting of static files, we migrated from Firebase to CommonsHost

More details on the trade-off in between both serverless providers is in the article

See more
Atlas logo

Atlas

33
0
Develop, deploy, and maintain your application anywhere. Use one console and one workflow from development to production
33
0
PROS OF ATLAS
    Be the first to leave a pro
    CONS OF ATLAS
      Be the first to leave a con

      related Atlas posts

      MongoDB Atlas logo

      MongoDB Atlas

      846
      34
      Deploy and scale a MongoDB cluster in the cloud with just a few clicks
      846
      34
      PROS OF MONGODB ATLAS
      • 10
        MongoDB SaaS for and by Mongo, makes it so easy
      • 6
        Amazon VPC peering
      • 4
        Granular role-based access controls
      • 4
        MongoDB atlas is GUItool through you can manage all DB
      • 3
        Use it anywhere
      • 3
        Cloud instance to be worked with
      • 3
        Built-in data browser
      • 1
        Simple and easy to integrate
      CONS OF MONGODB ATLAS
        Be the first to leave a con

        related MongoDB Atlas posts

        Praveen Mooli
        Engineering Manager at Taylor and Francis · | 19 upvotes · 4M views

        We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

        To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

        To build #Webapps we decided to use Angular 2 with RxJS

        #Devops - GitHub , Travis CI , Terraform , Docker , Serverless

        See more

        Repost

        Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

        Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

        Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

        Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

        See more
        AWS Lambda logo

        AWS Lambda

        24.2K
        432
        Automatically run code in response to modifications to objects in Amazon S3 buckets, messages in Kinesis streams, or...
        24.2K
        432
        PROS OF AWS LAMBDA
        • 129
          No infrastructure
        • 83
          Cheap
        • 70
          Quick
        • 59
          Stateless
        • 47
          No deploy, no server, great sleep
        • 12
          AWS Lambda went down taking many sites with it
        • 6
          Event Driven Governance
        • 6
          Extensive API
        • 6
          Auto scale and cost effective
        • 6
          Easy to deploy
        • 5
          VPC Support
        • 3
          Integrated with various AWS services
        CONS OF AWS LAMBDA
        • 7
          Cant execute ruby or go
        • 3
          Compute time limited
        • 1
          Can't execute PHP w/o significant effort

        related AWS Lambda posts

        Jeyabalaji Subramanian

        Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

        We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

        Based on the above criteria, we selected the following tools to perform the end to end data replication:

        We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

        We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

        In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

        Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

        In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

        See more
        Tim Nolet

        Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

        We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

        Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

        Enough biz talk, onto tech. The challenges were:

        • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
        • Update API and back end services to handle and enforce plan limits.
        • Update the UI to kindly state plan limits are in effect on some part of the UI.
        • Update the pricing page to reflect all changes.
        • Keep the actual processing backend, storage and API's as untouched as possible.

        In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

        1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
        2. The Vue.js frontend reads these from the vuex store on login.
        3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
        4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

        Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

        What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

        Hope this helps anyone building out their SaaS and is in a similar situation.

        See more
        GraphQL logo

        GraphQL

        34K
        310
        A data query language and runtime
        34K
        310
        PROS OF GRAPHQL
        • 75
          Schemas defined by the requests made by the user
        • 63
          Will replace RESTful interfaces
        • 62
          The future of API's
        • 49
          The future of databases
        • 13
          Self-documenting
        • 12
          Get many resources in a single request
        • 6
          Query Language
        • 6
          Ask for what you need, get exactly that
        • 3
          Fetch different resources in one request
        • 3
          Type system
        • 3
          Evolve your API without versions
        • 2
          Ease of client creation
        • 2
          GraphiQL
        • 2
          Easy setup
        • 1
          "Open" document
        • 1
          Fast prototyping
        • 1
          Supports subscription
        • 1
          Standard
        • 1
          Good for apps that query at build time. (SSR/Gatsby)
        • 1
          1. Describe your data
        • 1
          Better versioning
        • 1
          Backed by Facebook
        • 1
          Easy to learn
        CONS OF GRAPHQL
        • 4
          Hard to migrate from GraphQL to another technology
        • 4
          More code to type.
        • 2
          Takes longer to build compared to schemaless.
        • 1
          No support for caching
        • 1
          All the pros sound like NFT pitches
        • 1
          No support for streaming
        • 1
          Works just like any other API at runtime
        • 1
          N+1 fetch problem
        • 1
          No built in security

        related GraphQL posts

        Shared insights
        on
        Node.jsNode.jsGraphQLGraphQLMongoDBMongoDB

        I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery

        For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:

        1. Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have

        2. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.

        3. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website

        See more
        Nick Rockwell
        SVP, Engineering at Fastly · | 46 upvotes · 4.3M views

        When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

        So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

        React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

        Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

        See more
        NGINX logo

        NGINX

        113.8K
        5.5K
        A high performance free open source web server powering busiest sites on the Internet.
        113.8K
        5.5K
        PROS OF NGINX
        • 1.4K
          High-performance http server
        • 894
          Performance
        • 730
          Easy to configure
        • 607
          Open source
        • 530
          Load balancer
        • 289
          Free
        • 288
          Scalability
        • 226
          Web server
        • 175
          Simplicity
        • 136
          Easy setup
        • 30
          Content caching
        • 21
          Web Accelerator
        • 15
          Capability
        • 14
          Fast
        • 12
          High-latency
        • 12
          Predictability
        • 8
          Reverse Proxy
        • 7
          Supports http/2
        • 7
          The best of them
        • 5
          Great Community
        • 5
          Lots of Modules
        • 5
          Enterprise version
        • 4
          High perfomance proxy server
        • 3
          Embedded Lua scripting
        • 3
          Streaming media delivery
        • 3
          Streaming media
        • 3
          Reversy Proxy
        • 2
          Blash
        • 2
          GRPC-Web
        • 2
          Lightweight
        • 2
          Fast and easy to set up
        • 2
          Slim
        • 2
          saltstack
        • 1
          Virtual hosting
        • 1
          Narrow focus. Easy to configure. Fast
        • 1
          Along with Redis Cache its the Most superior
        • 1
          Ingress controller
        CONS OF NGINX
        • 10
          Advanced features require subscription

        related NGINX posts

        Simon Reymann
        Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 11.9M views

        Our whole DevOps stack consists of the following tools:

        • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
        • Respectively Git as revision control system
        • SourceTree as Git GUI
        • Visual Studio Code as IDE
        • CircleCI for continuous integration (automatize development process)
        • Prettier / TSLint / ESLint as code linter
        • SonarQube as quality gate
        • Docker as container management (incl. Docker Compose for multi-container application management)
        • VirtualBox for operating system simulation tests
        • Kubernetes as cluster management for docker containers
        • Heroku for deploying in test environments
        • nginx as web server (preferably used as facade server in production environment)
        • SSLMate (using OpenSSL) for certificate management
        • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
        • PostgreSQL as preferred database system
        • Redis as preferred in-memory database/store (great for caching)

        The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

        • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
        • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
        • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
        • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
        • Scalability: All-in-one framework for distributed systems.
        • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
        See more
        John-Daniel Trask
        Co-founder & CEO at Raygun · | 19 upvotes · 496.6K views

        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

        See more
        Apache HTTP Server logo

        Apache HTTP Server

        64.6K
        1.4K
        Open-source HTTP server for modern operating systems including UNIX and Windows
        64.6K
        1.4K
        PROS OF APACHE HTTP SERVER
        • 479
          Web server
        • 305
          Most widely-used web server
        • 217
          Virtual hosting
        • 148
          Fast
        • 138
          Ssl support
        • 44
          Since 1996
        • 28
          Asynchronous
        • 5
          Robust
        • 4
          Proven over many years
        • 2
          Mature
        • 2
          Perfomance
        • 1
          Perfect Support
        • 0
          Many available modules
        • 0
          Many available modules
        CONS OF APACHE HTTP SERVER
        • 4
          Hard to set up

        related Apache HTTP Server posts

        Nick Rockwell
        SVP, Engineering at Fastly · | 46 upvotes · 4.3M views

        When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

        So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

        React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

        Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

        See more
        Tim Abbott
        Shared insights
        on
        NGINXNGINXApache HTTP ServerApache HTTP Server
        at

        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
        Amazon EC2 logo

        Amazon EC2

        48.5K
        2.5K
        Scalable, pay-as-you-go compute capacity in the cloud
        48.5K
        2.5K
        PROS OF AMAZON EC2
        • 647
          Quick and reliable cloud servers
        • 515
          Scalability
        • 393
          Easy management
        • 277
          Low cost
        • 271
          Auto-scaling
        • 89
          Market leader
        • 80
          Backed by amazon
        • 79
          Reliable
        • 67
          Free tier
        • 58
          Easy management, scalability
        • 13
          Flexible
        • 10
          Easy to Start
        • 9
          Widely used
        • 9
          Web-scale
        • 9
          Elastic
        • 7
          Node.js API
        • 5
          Industry Standard
        • 4
          Lots of configuration options
        • 2
          GPU instances
        • 1
          Simpler to understand and learn
        • 1
          Extremely simple to use
        • 1
          Amazing for individuals
        • 1
          All the Open Source CLI tools you could want.
        CONS OF AMAZON EC2
        • 14
          Ui could use a lot of work
        • 6
          High learning curve when compared to PaaS
        • 3
          Extremely poor CPU performance

        related Amazon EC2 posts

        Ashish Singh
        Tech Lead, Big Data Platform at Pinterest · | 38 upvotes · 3.4M views

        To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

        Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

        We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

        Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

        Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

        #BigData #AWS #DataScience #DataEngineering

        See more
        Simon Reymann
        Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 11.9M views

        Our whole DevOps stack consists of the following tools:

        • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
        • Respectively Git as revision control system
        • SourceTree as Git GUI
        • Visual Studio Code as IDE
        • CircleCI for continuous integration (automatize development process)
        • Prettier / TSLint / ESLint as code linter
        • SonarQube as quality gate
        • Docker as container management (incl. Docker Compose for multi-container application management)
        • VirtualBox for operating system simulation tests
        • Kubernetes as cluster management for docker containers
        • Heroku for deploying in test environments
        • nginx as web server (preferably used as facade server in production environment)
        • SSLMate (using OpenSSL) for certificate management
        • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
        • PostgreSQL as preferred database system
        • Redis as preferred in-memory database/store (great for caching)

        The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

        • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
        • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
        • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
        • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
        • Scalability: All-in-one framework for distributed systems.
        • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
        See more