GraphQL : Productive on front-end slows down the backend development
Anytime I talk to frontend developers their opinion on having a GraphQL API the replies i hear are "wow amazing productivity" , " no more under-fetching", " get all you need in one request", "everything comes from the backend with the correct data structure", "my productivity increased drastically" .
When I talk to backend or fullstack developers they don't seem to be so sure about it or at least not for short term projects. That is because a GraphQL API adds some overhead you need to define lots of GraphQL definitions/ types/ schema and also to solve the notorious N+1 efficiency problem.
Is there a way around it ? could we get the best speed on the frontend and mitigate somehow the overhead on the backend?
Some solutions I found:
AWS Amplify has as one of their main selling points generating a GraphQL backend in minutes, but for some reason AWS Amplify doesn't seem to be a big success (even less among Indie developers)
Hasura.io came and offered just that: GraphQL backend build in minutes based on a database. While there are ways to customize and extend the CRUD GraphQL API, one modify the code of the GrqphQL queries( but it is visible). For business logic queries one needs to create a separate service , and integrate it in the schema(it's easy to plug another service/Api)
amplication.com auto-generates the GraphQL backend in Nest/Node, the output is generated code as one would write it, everything is there and can be changed to the last semicolon. - honestly I would expect this tool to have a wider adoption, but for some reason I see it having low engagement in social media and sometimes commenters even pick on the fact that the name "amplication" is too similar to "Amplify" (from AWS). Other times people say they do not understand their value proposition.
Later edit from from comments:
https://stepzen.com It’s a tool to generate GraphQL APIs from existing data sources like a database or api, in a declarative way.
Not yet done useGenerated.com auto-generates the GraphQL backend in Nest/Node similar to amplication but it will also create data fetching React hooks for list create edit update pages.
Have run multiple products on Hasura. FWIW Hasura does not use resolvers; it compiles SQL statements from the GraphQL queries (https://hasura.io/docs/latest/getting-started/how-it-works/index/#resolvers). I wouldn't call it a black box at all, especially since you can preview the exact SQL it will use when the query/mutation is executed.
For mutations and queries that require business logic I use custom actions in Hasura and send the payload to NestJS/Prisma services.
Authorization is role-based (configured in Hasura) and backs into a fairly simple service that implements Okta and does a role lookup for the given application.
Generally back-end dev is speedy as most queries and mutations don't require any work. Hasura has webhook configurations for after insert/update/delete events and I send those to a custom service that translates the Hasura payloads to a RabbitMQ publish call.
this looks good. Is what I recommend for lots of projects.
Thanks for a better explanation on Hasura
This is a great statement and one of the biggest reasons we’ve created StepZen https://stepzen.com
It’s a tool to generate GraphQL APIs from existing data sources like a database or api, in a declarative way. Changes to the GraphQL API are made in GraphQL SDL only, meaning you don’t have to write any resolvers. Also, it handles performance optimizations like caching and the N+1 problem when needing to make round trips to your database.
Would love you feedback!
Hey! I was just introduced to this new platform by one of their founders, from my lay-perspective it appears to address a similar goal/use-case to yours. Would you say that StepZen and Wundergraph are direct competitors? If so what distinguishing features; if not, why not? Just curious, not trying to put you on the spot. I'm still trying to find my "perfect" tech stack for some of my projects.
https://wundergraph.com/
Hey, I'm the founder of WunderGraph and would like to add some context here. Both StepZen and WunderGraph are declarative. They've decided to use GraphQL SQL for the configuration, while WunderGraph uses TypeScript for configuration, custom Middleware, etc...
It's now almost 3 years ago when I tried the SDL approach (https://github.com/jensneuse/graphql-gateway/blob/master/schema.graphql) but quickly abandoned it.
The biggest problem you'll run into when using GraphQL as a configuration language is that it lacks critical features like generics. It's impossible to declaratively define a set of middleware functions and attach them to multiple root fields. As you can see in my example, the schema has lots of directives and it's really hard to actually understand what's happening. TypeScript is simply a better language for configuration. But it's not just about configuration. Once you add more complex use cases, with authentication and multi-tenant authorization, it's inevitable to write custom hooks e.g. to inject secrets per tenant. If you're using GraphQL as your configuration language, you have to build a bridge between this custom logic and the GraphQL SDL. Everything is possible, but the developer experience will suffer.
A few more key differentiators:
Most if not all GraphQL solutions expose the GraphQL API to the client. WunderGraph exposes a JSON-RPC to the client, much like tRPC. Why? Security and performance. When you write a GraphQL Operation, we compile it into an RPC endpoint and generate a typesafe client for you, e.g. using SWR. (https://github.com/wundergraph/wundergraph/tree/main/examples/nextjs-swr)
WunderGraph is open source (Apache 2.0) and can easily be self-hosted. WunderGraph is built on top of graphql-go-tools (https://github.com/wundergraph/graphql-go-tools, MIT licensed), a generic GraphQL Gateway implementation, written in Go, used by many large enterprises and made rock solid over the period of many years. I personally would never trust a proprietary closed-source solution which I cannot self-host.
If you have any further questions, please comment or reach out.
StepZen has a declarative approach, which doesn’t require you to write JavaScript code. Meaning you only write the schema in GraphQL SDL and have no additional learning curve in understanding a new framework. Or a stuck to a given programming language. Also, you could use a Docker image to serve the GraphQL API yourself or use the multi-tenant cloud version built by ex-Google engineers.
If you already have a data source you can generate the GraphQL API by running the “stepzen import postgresql|mysql|curl|graphql” command. Or use one of the custom directives to build the GraphQL schema yourself - again in just GraphQL SDL https://stepzen.com/docs/connecting-backends
cool i have added it to the post
What a wonderful post! excellent stuff in this article.
Do you really need graphql in the first place? Do you expose your API publicly?
If devs are fullstack enough tRPC + Prisma will also work well
develop a bit what are the pluses and minues of tRPC vs graphql? I think it's a newer technology / approach, I mean we have full stack with REST since forever, fullstack with GraphQL since like 6 years (more mainstream) and only recently have heard of tRPC.
If you just need to move data from dB to frontend, you don't need graphql and avoid over/underfetching, just have fullstack engineers being able to select dB data themselves directly.
GraphQL adds an extra layer to maintain that is not really needed for a lot of apps. In particular if your API is called by only a single client like a website. Instead you could have flexibility to implement without too much ceremony rpc services that solve exactly very specific UI needs.
thanks for the answer.
One more question:
where does the custom/business logic belong in this paradigm ? is it all on frontend or are there ways to define on the backend what happens to the data before being saved in database and before being served to client?
It's like calling a function from the frontend directly to the backend. So of course you'll need to handle security or retro-compatibility if you need it
I think the biggest benefit of graphql comes when you use it as a middle layer between the backend and frontend for a large organization with a lot of backend services and APIs managed by different teams. This allows you to consolidate a lot different requests in the same region as the backend services and consolidate them in a single response to the frontend. I don't think it speeds up anyone's work as it's more overhead, but it helps with performance and bloated frontend code.
These are the kind of meaty discussions I come to IH for. Wondering what makes people say Amplify/Appsync is not more popular? Wondering since I am just scratching the surface of it studying online Yan Cui's masterclass and other material for an MVP idea.
I don't know about Appsync but for Amplify my POV :
It sounded like a big thing 2-3 years ago and it was supposed to make development way faster. I mean when time is so scarce getting big parts of backend and even frontend auto generated was huge promise.
Then now i just don't hear about it, so I try to check and i see some youtube videos with little views (for what I expected from a big company). influencers I follow and are focused on developing web apps as fast as possible do not seem to cover it. i went and asked people that used it and from the few I found all seem to have migrated away already.
Thx for the lengthy perspective.
Interesting. I don't have enough production or backend experience to speak to this - mainly frontend dev here, fullstack by necessity of working solo-independent.
But there are three new products that caught my attention lately that you may find relevant:
The first two of them are explicitly focused on GraphQL, and the 3rd, SurrealDB, will be integrating GraphQL soon, but bigger than that, has a vision for integrating the entire backend (see this thread https://discord.com/channels/902568124350599239/1027296296052215809)
Good video overview of SurrealDB that got me really excited: https://www.youtube.com/watch?v=DPQbuW9dQ7w
"fullstack by necessity of working solo-independent" This is the target and best position to be as a indie for most projects I can imagine.
can you describe the workflow with grafbase or wundergraph? I see that creates a CRUD backend and that would solve lots of usecases, but what about when you need some business logic? how did you do it or how do you plan to do that ? ( see SausageComa description for Hasura)
I am using GraphQL for all my app. It's built on Symfony ( PHP) framework.
I have developed my own code generator that creates Model and GraphQL CRUD operation.
Finally it also generates frontend code ( built-in Quasar Framework - Vue Js )
All of this get done in a matter of 2 minutes. It gets done by executing 2-3 command in command line
that is cool!
what kind of frontend code it generates ? an admin interface? or generic forms based on models ?
p.s I'm doing same thing but for Node/NestJS framework Prisma ORM and React at useGenerated.com but it's not done yet so i did not put it in the main article.
It generates admin interface with following
List.vue
Show.vue
Update.vue
Create.vue
Form.vue
Repository.js
Model.js
Translation.js
It's full CRUD operation along with permissions applied
it's not my stack but it looks good ! do you use it as a product or just as your competitive advantage to develop projects for others ?
Right now I am using it as a competitive advantage.
I have built 3 SaaS products based on this stack.
I am planning to release it as a product in future
i have asked on reddit as well https://www.reddit.com/r/graphql/comments/xyywpz/graphql_for_small_indiesideprojects_productive_on/ maybe there are some useful opinions there, I'm sure not everyone there is here as well.
This comment has been voted down. Click to show.