Apollo-server: Apollo graphql-server vs loopback-graphql vs sails-graphql

Created on 4 Apr 2017 · 3Comments · Source: apollographql/apollo-server

Hello everybody,

Me and my team are coming from a diverse background (some were using meteor, some sails, ...) and we are hoping to consolidate our skills in a single stack.

We picked graphql as a substitute for REST, with Apollo Client on the frontend, but we can't make up our mind about which backend to use.

I was looking with interest at Apollo Server (best GQL support, worst proficiency), but some devs seem to prefer Sails (worst GQL support, best proficiency) or loopback (good GQL support, average proficiency).

Since you made a comparison to express-graphql on the home page, I was hoping that you could elaborate more on these other two server options.

My specific questions are:

1) Which option offers the best productivity in medium/long term?
2) What are the technical points of strength and weaknesses of each solution?

I'm looking at you @stubailo , I bet you have something to say :1st_place_medal:

Source

espoal

👍1

Most helpful comment

@servermeta I think @smolinari's hits the nail on the head. graphql-server doesn't get in your way. It's most useful for building a GraphQL server in front of any kind of backend. sails-graphql and loopback-graphql are for creating servers from sails or loopback models specifically. If you have one of those, they can probably save you time, but if you want to keep maximum flexibility I'd recommend using a more "vanilla" GraphQL server.

helfer on 10 Apr 2017

👍4

All 3 comments

I believe, if you step into a (proper) GraphQL world, for which it was purposely built, i.e. with reactive UI clients, you should also be stepping out of the MVC paradigm. So, being Sails is MVC, mixing the two is sort of a clashing of paradigms. I am not sure using Sails with GraphQL would be completely effective. it is also not directly supported by Sails. That being said, since GraphQL is built to be a thin API layer, it can wrap a Sails back-end fairly easily, I believe. Again, I am not sure if that would be effective, especially if you are starting from scratch.

Loopback, on the other hand, looks like it would be more in the direction of supporting the right kind of paradigm. If the Loopback-GraphQL module would also offer Loopback's model -> API building tools (i.e. creating GraphQL Types, Mutations and Resolvers automatically), along with built in authentication, authorization and permissions system, that would be a pretty big win over straight Apollo. If you'll notice, the Loopback-GraphQL module is using Apollo Server. Though, it doesn't seem like the Loopback-GraphQL module offers what I just mentioned and GraphQL is also not directly supported by Loopback.

This is the realm of GraphQL that still needs a good bit of work. Full backends. There are things done to add to a GraphQL backend and connecting ORMs or ODMs isn't very difficult. How your back-end does its business logic is basically up to you. I believe Apollo is designed specifically to stay out of your way in this respect.

Scott