Alternatives to Reindex logo

Alternatives to Reindex

Optimize, Heroku, Google App Engine, AWS Elastic Beanstalk, and Apollo are the most popular alternatives and competitors to Reindex.
3
12
+ 1
0

What is Reindex and what are its top alternatives?

Reindex makes it easy to set up a GraphQL backend that stores the data for your application, handles security with user authentication and permissions, and is easy to extend with webhooks. You can focus on building an awesome app for your users.
Reindex is a tool in the Platform as a Service category of a tech stack.

Reindex alternatives & related posts

Optimize logo

Optimize

61
36
0
61
36
+ 1
0
A/B testing and personalization platform
    Be the first to leave a pro
    Optimize logo
    Optimize
    VS
    Reindex logo
    Reindex
    Heroku logo

    Heroku

    7.9K
    5.5K
    3.1K
    7.9K
    5.5K
    + 1
    3.1K
    Build, deliver, monitor and scale web apps and APIs with a trail blazing developer experience.
    Heroku logo
    Heroku
    VS
    Reindex logo
    Reindex

    related Heroku posts

    Tim Nolet
    Tim Nolet
    Founder, Engineer & Dishwasher at Checkly · | 18 upvotes · 207K views
    atChecklyHQChecklyHQ
    vuex
    vuex
    Knex.js
    Knex.js
    PostgreSQL
    PostgreSQL
    Amazon S3
    Amazon S3
    AWS Lambda
    AWS Lambda
    Vue.js
    Vue.js
    hapi
    hapi
    Node.js
    Node.js
    GitHub
    GitHub
    Docker
    Docker
    Heroku
    Heroku

    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
    Russel Werner
    Russel Werner
    Lead Engineer at StackShare · | 17 upvotes · 195.5K views
    atStackShareStackShare
    Redis
    Redis
    CircleCI
    CircleCI
    Webpack
    Webpack
    Amazon CloudFront
    Amazon CloudFront
    Amazon S3
    Amazon S3
    GitHub
    GitHub
    Heroku
    Heroku
    Rails
    Rails
    Node.js
    Node.js
    Apollo
    Apollo
    Glamorous
    Glamorous
    React
    React
    #FrontEndRepoSplit
    #Microservices
    #SSR
    #StackDecisionsLaunch

    StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

    Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

    #StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

    See more

    related Google App Engine posts

    Nick Rockwell
    Nick Rockwell
    CTO at NY Times · | 9 upvotes · 28K views
    atThe New York TimesThe New York Times
    Kubernetes
    Kubernetes
    Google Kubernetes Engine
    Google Kubernetes Engine
    Google App Engine
    Google App Engine
    Amazon EC2
    Amazon EC2
    #Migration
    #Cloudmigration
    #AWStoGCPmigration
    #GCP
    #AWS

    So, the shift from Amazon EC2 to Google App Engine and generally #AWS to #GCP was a long decision and in the end, it's one that we've taken with eyes open and that we reserve the right to modify at any time. And to be clear, we continue to do a lot of stuff with AWS. But, by default, the content of the decision was, for our consumer-facing products, we're going to use GCP first. And if there's some reason why we don't think that's going to work out great, then we'll happily use AWS. In practice, that hasn't really happened. We've been able to meet almost 100% of our needs in GCP.

    So it's basically mostly Google Kubernetes Engine , we're mostly running stuff on Kubernetes right now.

    #AWStoGCPmigration #cloudmigration #migration

    See more

    related AWS Elastic Beanstalk posts

    Julien DeFrance
    Julien DeFrance
    Principal Software Engineer at Tophatter · | 16 upvotes · 367.1K views
    atSmartZipSmartZip
    Amazon DynamoDB
    Amazon DynamoDB
    Ruby
    Ruby
    Node.js
    Node.js
    AWS Lambda
    AWS Lambda
    New Relic
    New Relic
    Amazon Elasticsearch Service
    Amazon Elasticsearch Service
    Elasticsearch
    Elasticsearch
    Superset
    Superset
    Amazon Quicksight
    Amazon Quicksight
    Amazon Redshift
    Amazon Redshift
    Zapier
    Zapier
    Segment
    Segment
    Amazon CloudFront
    Amazon CloudFront
    Memcached
    Memcached
    Amazon ElastiCache
    Amazon ElastiCache
    Amazon RDS for Aurora
    Amazon RDS for Aurora
    MySQL
    MySQL
    Amazon RDS
    Amazon RDS
    Amazon S3
    Amazon S3
    Docker
    Docker
    Capistrano
    Capistrano
    AWS Elastic Beanstalk
    AWS Elastic Beanstalk
    Rails API
    Rails API
    Rails
    Rails
    Algolia
    Algolia

    Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

    I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

    For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

    Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

    Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

    Future improvements / technology decisions included:

    Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

    As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

    One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

    See more
    Amazon ElastiCache
    Amazon ElastiCache
    Amazon Elasticsearch Service
    Amazon Elasticsearch Service
    AWS Elastic Load Balancing (ELB)
    AWS Elastic Load Balancing (ELB)
    Memcached
    Memcached
    Redis
    Redis
    Python
    Python
    AWS Lambda
    AWS Lambda
    Amazon RDS
    Amazon RDS
    Microsoft SQL Server
    Microsoft SQL Server
    MariaDB
    MariaDB
    Amazon RDS for PostgreSQL
    Amazon RDS for PostgreSQL
    Rails
    Rails
    Ruby
    Ruby
    Heroku
    Heroku
    AWS Elastic Beanstalk
    AWS Elastic Beanstalk

    We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.

    We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.

    In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.

    Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache

    See more
    Apollo logo

    Apollo

    814
    578
    9
    814
    578
    + 1
    9
    GraphQL server for Express, Connect, Hapi, Koa and more
    Apollo logo
    Apollo
    VS
    Reindex logo
    Reindex

    related Apollo posts

    Nick Rockwell
    Nick Rockwell
    CTO at NY Times · | 27 upvotes · 313.3K views
    atThe New York TimesThe New York Times
    Apache HTTP Server
    Apache HTTP Server
    Kafka
    Kafka
    Node.js
    Node.js
    GraphQL
    GraphQL
    Apollo
    Apollo
    React
    React
    PHP
    PHP
    MySQL
    MySQL

    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
    Adam Neary
    Adam Neary
    Engineer at Airbnb · | 26 upvotes · 278.9K views
    atAirbnbAirbnb
    Apollo
    Apollo
    GraphQL Playground
    GraphQL Playground
    GraphQL
    GraphQL
    #Prisma
    #BackendDrivenUI

    At Airbnb we use GraphQL Unions for a "Backend-Driven UI." We have built a system where a very dynamic page is constructed based on a query that will return an array of some set of possible “sections.” These sections are responsive and define the UI completely.

    The central file that manages this would be a generated file. Since the list of possible sections is quite large (~50 sections today for Search), it also presumes we have a sane mechanism for lazy-loading components with server rendering, which is a topic for another post. Suffice it to say, we do not need to package all possible sections in a massive bundle to account for everything up front.

    Each section component defines its own query fragment, colocated with the section’s component code. This is the general idea of Backend-Driven UI at Airbnb. It’s used in a number of places, including Search, Trip Planner, Host tools, and various landing pages. We use this as our starting point, and then in the demo show how to (1) make and update to an existing section, and (2) add a new section.

    While building your product, you want to be able to explore your schema, discovering field names and testing out potential queries on live development data. We achieve that today with GraphQL Playground, the work of our friends at #Prisma. The tools come standard with Apollo Server.

    #BackendDrivenUI

    See more

    related OpenShift posts

    Conor Myhrvold
    Conor Myhrvold
    Tech Brand Mgr, Office of CTO at Uber · | 16 upvotes · 708.8K views
    atUber TechnologiesUber Technologies
    Apache Spark
    Apache Spark
    C#
    C#
    OpenShift
    OpenShift
    JavaScript
    JavaScript
    Kubernetes
    Kubernetes
    C++
    C++
    Go
    Go
    Node.js
    Node.js
    Java
    Java
    Python
    Python
    Jaeger
    Jaeger

    How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

    Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

    Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

    https://eng.uber.com/distributed-tracing/

    (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

    Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

    See more
    Michael Ionita
    Michael Ionita
    CTO at Walls.io GmbH · | 6 upvotes · 19.3K views
    atWalls.ioWalls.io
    OpenShift
    OpenShift
    Kubernetes
    Kubernetes

    We use Kubernetes because we decided to migrate to a hosted cluster (not AWS) and still be able to scale our clusters up and down depending on load. By wrapping it with OpenShift we are now able to easily adapt to demand but also able to separate concerns into separate Pods depending on use-cases we have.

    See more
    Azure Websites logo

    Azure Websites

    294
    231
    21
    294
    231
    + 1
    21
    Deploy and scale modern websites and web apps in seconds
    Azure Websites logo
    Azure Websites
    VS
    Reindex logo
    Reindex
    Dokku logo

    Dokku

    100
    90
    58
    100
    90
    + 1
    58
    Docker powered mini-Heroku in around 100 lines of Bash
    Dokku logo
    Dokku
    VS
    Reindex logo
    Reindex
    MongoDB Stitch logo

    MongoDB Stitch

    86
    102
    3
    86
    102
    + 1
    3
    Backend as a Service for web and mobile applications
    MongoDB Stitch logo
    MongoDB Stitch
    VS
    Reindex logo
    Reindex

    related MongoDB Stitch posts

    Jeyabalaji Subramanian
    Jeyabalaji Subramanian
    CTO at FundsCorner · | 24 upvotes · 263.7K views
    atFundsCornerFundsCorner
    Zappa
    Zappa
    AWS Lambda
    AWS Lambda
    SQLAlchemy
    SQLAlchemy
    Python
    Python
    Amazon SQS
    Amazon SQS
    Node.js
    Node.js
    MongoDB Stitch
    MongoDB Stitch
    PostgreSQL
    PostgreSQL
    MongoDB
    MongoDB

    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
    Cloud Foundry logo

    Cloud Foundry

    84
    108
    4
    84
    108
    + 1
    4
    Deploy and scale applications in seconds on your choice of private or public cloud
    Cloud Foundry logo
    Cloud Foundry
    VS
    Reindex logo
    Reindex
    Apache Camel logo

    Apache Camel

    64
    23
    2
    64
    23
    + 1
    2
    A versatile open source integration framework
    Apache Camel logo
    Apache Camel
    VS
    Reindex logo
    Reindex
    jFrog logo

    jFrog

    50
    9
    0
    50
    9
    + 1
    0
    Universal Artifact Management
      Be the first to leave a pro
      jFrog logo
      jFrog
      VS
      Reindex logo
      Reindex
      Azure App Service logo

      Azure App Service

      47
      18
      0
      47
      18
      + 1
      0
      Build, deploy, and scale web apps on a fully managed platform
        Be the first to leave a pro
        Azure App Service logo
        Azure App Service
        VS
        Reindex logo
        Reindex
        PythonAnywhere logo

        PythonAnywhere

        45
        64
        19
        45
        64
        + 1
        19
        Micro PaaS for Python web apps. Develop and host Python from your browser
        PythonAnywhere logo
        PythonAnywhere
        VS
        Reindex logo
        Reindex
        Envoyer logo

        Envoyer

        38
        24
        2
        38
        24
        + 1
        2
        A brand new way to deploy PHP and Laravel applications with zero downtime
        Envoyer logo
        Envoyer
        VS
        Reindex logo
        Reindex
        Hasura logo

        Hasura

        37
        54
        3
        37
        54
        + 1
        3
        An open source GraphQL engine that deploys instant, realtime GraphQL APIs on any Postgres database.
        Hasura logo
        Hasura
        VS
        Reindex logo
        Reindex
        Deis logo

        Deis

        26
        38
        53
        26
        38
        + 1
        53
        Open Source PaaS that builds upon Docker and CoreOS to provide a lightweight PaaS with a Heroku-inspired workflow