Why GraphQL Between Microservices Is the Worst & Best Idea • Uri Goldshtein • GOTO 2020

[@r0eb]

Good talk! Thanks. Which program uses to create the awesome graphics in your Talk?

[@mateja176]

The illustrations are created by a talented friend of his whereas the slides and animations where created in Apple Keynote. Moreover, Uri proposes that such animations can just as easy be created in PowerPoint.

[@malcommiya5940]

What did you use for the graphics? As in the Softwares?

[@nickpearce2968]

A great code accelerator inside of a service boundary.

[@stanislavstankov5160]

thanks for sharing

[@georgesmith9178]

What are these fancy graphics recorded with? Is it some newfangled tool? Special thanks to anyone who answers this question.

[@dazraf]

Love this talk. Super exciting.

[@yasserdead1]

Great presentation! Any recommendations for a beginner writing an API from scratch? GraphQL, Swagger, OpenAPI: a lot of technologies, but where to begin?

[@mahendarreddykodimala4846]

+1

[@armenarz4062]

what's why ? because GraphQL equals to slow development

[@w0083e5c]

what? if the answer to a complex system is 6 words, i doubt your judgement

[@armenarz4062]

@@w0083e5c I guess your experience is not much with real complex systems.

[@GaborMolnar88]

Could you explain why?

[@armenarz4062]

@@GaborMolnar88 Because microservices intercommunication within a system can be in any way, it depend from your team skills, your business requirements, your cloud type, product target. Within a one system can be different subsystems with different types of intercommunication . GraphQL add additional complexity to the system, because it is not so manageable as HTTP connections, it is slow than HTTP connections. Also in the Cloud for example in the Azure, your system will run in the same network so http overhead is a minimal. Intercommunication is the not main problem in the complex system. Main problem traffic control, separation of API for frontend, separation API for internal use, separation API for public access, different type of gateways for web for mobile, for GPS, internal subsystems, event based pipelines, internal jobs, integration hubs and /etc. Your microservices is not looks like one to another, one of problem architecture of one microservice in the system. Other problem databases count, you must understand 100 microservices and 100 main databases it is a costly and wrong architecture. It will fail. If you have 100 microservices, you must have Chief Architect, who code. You must have at least 4-5 teams...:)

[@BlueBockser]

@@armenarz4062 I don't quite get your point. Why do you compare HTTP to GraphQL? One is a protocol, the other a query language. A more sensible comparison would be ReST and GraphQL, both of which have pros and cons. GraphQL makes the most sense when you deal with large and complex data structures since it can avoid the overhead of sending huge amounts of irrelevant data. Also, you say that GraphQL adds complexity to the system. That is true, but it's the way technology goes when requirements become more complex. Having separate APIs for frontends, internal use, external use etc. also adds complexity. Only now a client might have to request different APIs to get all the data it needs, whereas that would be a single query with GraphQL. Most of your other points are just off-topic. Why should it matter in the context of GraphQL whether your system has 1, 10 or 100 databases? Why should it matter what a specific individual team is good at? We're discussing a technology here, not something else. I'm not saying GraphQL is a good fit for all use cases, but I think the points you presented are just not true or relevant.

[@Irresponsibleful]

that hair in the mic is annoying

[@UriGoldshtein]

Yes in all my talks after that I moved to AirPods, sorry about that :)