Apollo vs tsuru: What are the differences?
Apollo: GraphQL server for Express, Connect, Hapi, Koa and more. Build a universal GraphQL API on top of your existing REST APIs, so you can ship new application features fast without waiting on backend changes; tsuru: Extensible and open source Platform as a Service software. tsuru is an open source polyglot cloud application platform (PaaS). With tsuru, you don’t need to think about servers at all. You can write apps in the programming language of your choice, back it with add-on resources such as SQL and NoSQL databases, memcached, redis, and many others. You manage your app using the tsuru command-line tool and you deploy code using the Git revision control system, all running on the tsuru infrastructure.
Apollo and tsuru can be primarily classified as "Platform as a Service" tools.
"From the creators of Meteor" is the primary reason why developers consider Apollo over the competitors, whereas "Very receptive to contributions" was stated as the key factor in picking tsuru.
Apollo and tsuru are both open source tools. It seems that Apollo with 7.53K GitHub stars and 935 forks on GitHub has more adoption than tsuru with 3.14K GitHub stars and 421 GitHub forks.
What is Apollo?
What is tsuru?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Apollo?
What are the cons of using tsuru?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
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
In my last side project, I built a web posting application that has similar features as Facebook and hosted on Heroku. The user can register an account, create posts, upload images and share with others. I took an advantage of graphql-subscriptions to handle realtime notifications in the comments section. Currently, I'm at the last stage of styling and building layouts.
For the #Backend I used graphql-yoga, Prisma, GraphQL with PostgreSQL database. For the #FrontEnd: React, styled-components with Apollo. The app is hosted on Heroku.
Tsuru allows developers the necessary and dreamed autonomy, maintaining the infrastructure department confident and is very business oriented as it improves the time to market with safety. Where is the magic?! It is not just starting to treat people as adults(that is mandatory), you also need a system that automatically recover itself(self-healing) after any mistake, misconfiguration, infrastructure problem, etc and (auto)scale easily as needed. We have it for about 4 years at Globo.com using Tsuru PaaS, one of the most loved projects we maintain, totally opensource, powered by Docker, no vendor lock-in, no comercial version(what we use is what we provide) and very receptive to new contributions, discussions, and fix of serious issues(stop the line mindset). Tsuru manages applications with millions of users with no headaches. The main value is that tsuru allowed a new and desired culture, finally developer can have the freedow they want to deploy(the freedom comes with responsability) - thousands of deploys/month and increasing - with increased stability/availability of ours portals We can finally rest calmally at night and in the weekends, letting tsuru dealing automatically with any operational problem may happen. Try it in your company, you too deserve to be happy! https://tsuru.io https://github.com/tsuru/tsuru