Satoshi Yamamoto
-Satoru Yamamoto
Follow us on
IT Freelance ProgrammerJune 3
Well... Polypoly...
Maybe it's just a hassle...
It slows down the development speed. Like.
No, well, I'm not trying to be stingy with you.
It's just that it's easier for the server side (API side) to take care of things as soon as the front side asks for help, rather than having to prepare various things on the server side in order to send the expected results to the front side.
Also, I felt that the TypeScript type was a little incompatible with the server side. I'm sure there may be a better solution on a case by case basis, but I haven't found it, and I've experienced some terrible type merging...
The auto-generated types returned by GraphQL Apolo are so squishy that they are very hard to read and you end up having to solve a type puzzle, which may or may not be a compromise.
If the server side sends RESTAPI carefully without using GraphQL, and if the team can work together to fix the server REST as soon as the front desk requests it, I don't think there is any advantage to using GraphQL.
That's what I think.
The learning cost is considerable, so, well, I don't know.
If I were in a position where I was like a god of the project and could decide anything... I wouldn't adopt it, or something like that.
But, projects that use GraphQL seem to be very difficult... (read more)
Profile photo of Masahiro Ishizuka
Profile photo of Hideki Ikemoto
Hideki Ikemoto
-Hideki Ikemoto
Follow me on Twitter
Backend EngineerJune 3, 2011
In conclusion, it is an organizational problem.
In Japan, GraphQL is used by Yahoo! and Mercari, for example.
Next.js + NestJS + GraphQL to a front-end that can keep up with changes - Shopping Coupon Case Study
We will show you what kind of struggles we had and what kind of innovations we made while innovating to modern front-end technology!
https://techblog.yahoo.co.jp/entry/2020121530052952/
Implementation of GraphQL Server with NestJS in Mercari Shops
I'm @mookjp, a Software Engineer at Sozo, and in my Aug. 10 article, "The Technology Stack of Mercari Shops and Why We Chose It," I presented an overview of the architecture of Mercari Shops. This article
https://engineering.mercari.com/blog/entry/20210818-mercari-shops-nestjs-graphql-server/
Both are built with microservices already on the backend and use GraphQL as a BFF, a pattern that is hard to manage on the client side with only a REST API.
On the other hand, GraphQL requires the following points to be considered when deploying. In particular, the N+1 problem and the cost of queries are critical.
Things to consider when implementing GraphQL
Hello, this is @sue71, Software Engineer at Souzou. This is the 13th day of the series: Behind the Scenes of MercariShops Development Vol. 2. I have previously discussed the technology stack of MercariMerukariShops and the reasons for selecting it to implement BFF.
https://engineering.mercari.com/blog/entry/20220303-concerns-with-using-graphql/
And if you are a startup and the front-end and back-end engineers are on the same team, you won't have much trouble with REST API. The communication costs are not that high.
To summarize, here is what I mean.
Very effective as a BFF for organizing microservices
There are some problems specific to GraphQL (N+1, query cost)
REST API is sufficient if front and back office are on the same team
For example, Technology Radar is still in Assess phase.
GraphQL | Technology Radar | Thoughtworks
We've seen many successful GraphQL implementations on our projects. We've seen some interesting patterns of use too, including GraphQL for server-side resource aggregation. That said, [...]
https://www.thoughtworks.com/radar/languages-and-frameworks/graphql
The back-end aggregation patterns I mentioned at the beginning of this article, such as Yahoo!
GraphQL for server-side resource aggregation | Technology Radar | Thoughtworks
We see more and more tools such as Apollo Federation that can aggregate multiple GraphQL endpoints into a single graph. However, we caution against misusing [...].
https://www.thoughtworks.com/radar/techniques/graphql-for-server-side-resource-aggregation
However, in the first place, the number of companies adopting microservices is small in Japan, and seems to be limited to a few mega-ventures.
So there is no motivation to adopt GraphQL, and this is the direct cause.
Therefore, in order to popularize GraphQL, it is necessary to popularize microservices. Of course, it is an anti-pattern to introduce microservices from the beginning, but I think it is possible for a company with a few dozen engineers to do so.
This is because the appropriate number of people per team is about 6±3, and when there are dozens of engineers, they must be divided into multiple teams, and it is difficult for multiple teams to do so monolithically.
The question thus boils down to "why can't medium-sized companies adopt microservices?" but I think this is more of an organizational problem than an engineer problem.
The reasons for this are discussed in this video.
However, in addition to the benefits, there is also a downside. Asynchronization inevitably leads to inconsistencies.
As a friend of mine actually wrote on Facebook, the product has been delivered, but the product is not in hand.
What Amazon does in this case is to give you a coupon for 300 yen.
This is very important.
In order to make the services loosely coupled, you have to accept inconsistencies.
What do you do with what you accept? Let's cover it with operations, which is what even Amazon does.
You don't solve it with technology. This is what accepting loosely coupled means.
You can't split up unless you change the way you think about quality, quality, and integrity, which is what we've been doing.
The same is true for data separation, and the same is true for message coordination, but to be asynchronous means to accept inconsistency.
If this is something you just can't do, give up microservices. It cannot be done.
To go microservices, you need to accept inconsistency (result consistency), and to do that, you need to "cover it in operations". Then, engineers alone cannot help. You need to involve the organization, including operations and business.
But as a result, most organizations can say, "We need to split the team and make it more agile for future growth. So let's go microservices. And then they gradually become slow and stop growing. So it's an organizational problem.
Well, microservices is just a means to an end, and there are ways to improve maintainability without changing the monolith. But I think most organizations have accumulated so much technical debt before that that they can't afford microservices.
I, an engineer with 17 years of experience, will explain the necessity of maintenance in a dead simple way to non-engineers who throw a lot of development tasks for business systems. |miyatake｜note
Day 5 of [Ateam Lifestyle x cyma Advent Calendar 2018] will be led by @gonjyu121 of Ateam Lifestyle Inc. Introduction Recently, web service management teams often include business operations and planning sales teams and engineering teams working together. In such cases, many engineers tend to have the problem that "quality maintenance, refactoring, and improvement issues (tasks) are not given high priority and cannot be started. ・・・・・・ For the non-engineers, this is a problem that they may have, "I know the engineers are great, but what are they doing to make it better?
https://note.com/gonjyu/n/nd7bf3efa0728
Views:14,000Views:106Highly ratedViews:3Shares
0 コメント:
コメントを投稿