> Accidental complexity is a bad thing and should be avoided if possible.
Yes. I absolutely agree.
Start with a monolith. Use server-side rendering if possible. Use SQLite instead of [wretched nosql abomination]. API development is a waste of time. The business doesn't give a shit about any of this. Just make it work, then make it "webscale".
Gall’s law: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
If you have never designed or developed software before, by all means try that.
Once you have reached at least junior level, start learning about how to split the system into subsystems and putting some additional thought into it.
The business doesn't give a shit about the implementation. Very true... that's why they hired you so that you fucking do. Just do your job.
If you want to work in finance, accounting, sales, investor relations, partnerships, business development or whatever, go do that. If you want to work creating software, start caring about how software is created, or at least don't ruin it for people that do.
If you decide to follow a business career path, you will find that they also have to care about their job, have attention to detail and care about good practices and compliance. In fact, that will also be the case for every occupation in every sector.
Performance isn't just latency - it's also about the requests and responses per second a service can handle.
GQL notoriously performs weaker to REST in this regard.
>When a user navigates to a page on a web app or deep links into a Single Page Application (SPA) or a particular view in a mobile app, the frontend application needs to call the backend service to fetch the data needed to render the view. With RESTful APIs, it is unlikely that a single call will be able to get all the data. Typically, one call is made, then the frontend code iterates through the results of that call and makes more API calls per result item to get all the data needed.
>For example, I don’t want to navigate through multiple screens to review my travel itinerary; I want to see the summary (including flights, car rental, and hotel reservation) all on one screen before I commit to making the purchase.
I disagree.
Sure, sometimes more than one restful call is made for just one page, but the example given, when architectured properly is just a user foreign key relationship to all its children (reservations flights, rentals, etc), which is just a single sql query.
I don't think the author really understand the flexibility of REST and how much it can emulate what GQL has to offer.
If you want specificity in your query fetching, just add query params or put them in the request body
And if it is the case that you really do need resources from different endpoints, what is preventing you to build that single endpoint in REST?
I may be wrong about this, but here's how I see things: I think the two main "variables that depend on" performance are latency and how much computer power you need. And the "variable that depend on" how much computer power you need are server costs, and the architecture of your application.
If we assume that REST serves more requests than GraphQL, but GraphQL is more flexible, that may be a trade off of dev time of the application vs a dev time of the infrastructure. Which would fit with more and more people using orchestration and things like that. That might be a very wrong assumption though.
> Performance isn't just latency - it's also about the requests and responses per second a service can handle.
Performance is 99% about latency. And, when having this conversation, we are typically talking about I/O-bound latency.
Assume you have a trivial computer system that can only process 1 thing at a time. The number of things you can process per unit time is inversely proportional to the amount of time it takes to process each thing. Adding more threads/cores to the mix does not change this fundamental equation. Many practical business systems have a large component of processing that must occur in a serial fashion.
Think:
Multiple computers: Milliseconds, One computer: Nanoseconds
How much more work can you do if you can finish each unit in 100ns vs 5ms? How would this impact the user experience? Is the reason you cant finish in 100ns because you are doing global illumination on the CPU or because you are waiting for [hipster noSQL solution] to return some packets to your application server?
In this comment you've made a claim that GQL is not only weaker than REST here, but notoriously weaker. The only argument that you seem to have made here is that a REST call "can" do the same type of things that are built into GraphQL.
You haven't supported your position that GraphQL is weaker at all. Everything that I have read, seen and heard is exactly the opposite. GraphQL seems to be the "I will never go back to REST" experience for virtually everybody I know in the field who has used it.
The other issue is that you're fighting the nature of REST itself to make it do more. Sure, you can make any API call take in specific input and send out exactly the output that you need...but REST API guidelines tend to preach exactly the opposite approach. The call should return one thing and if you want more, you need to get it yourself.
I'm open to hearing your perspective on this, but if you're going to make a claim like that you really need to support it.
No matter how careful you are with the initial architecture of your microservices system, it is inevitable to re-architect as you go. Specifically to properly distribute service responsibilities.
if you're not sure what the correct decomposition of responsibilities into services / components / libraries is, that suggests structuring the project in a way (at least initially, until you're feeling highly directional pain to suggest a refactoring direction) that the cost of rearranging responsibilities is low. as well as starting with a monolith, that also suggests starting with everything in the one source control repository to make it trivial to refactor and rearrange across swathes of code in lockstep.
in some organisations the amount of meetings and overhead scales proportionally to the number of network connections in the architecture diagram, so that also suggests replacing external dependencies with in-process function calls wherever possible.
But microservices make it a lot more complex. Start with a monolith in an easily refactorable language. Microservices are a solution to a problem you WISH you had.
> No matter how careful you are with the initial architecture of your microservices system, it is inevitable to re-architect as you go.
Isn't this true for all software systems? If anything, microservice architectures just make it easier to re-architect parts of the system, thus lower the bar to actually do the work.
Large systems are like the living organisms that need to be cared and grown. We can't predict everything as our children grow, but we make sure they're moving on a right direction and help them with difficulties where possible.
Systems grow from toddlers to old men, so do the businesses. They just evolve and adapt, otherwise they die.
Isn't it more work to create REST services and GraphQl to implement BFF pattern. Also why is GraphQL bad for data services? The N+1 problem that author mentions is easily solvable by dataloaders. Why create two layers on backend?
If the underlying data store is SQL capable, then dataloaders are just a hack trying to do what the SQL engine already does in much more efficient way. Much better to map the GraphQL query to proper SQL query avoiding the round trips.
I strongly believe in simplicity and maintainability of the applications, even at the cost of some flexibility. I like the simplicity of REST when compared to the GQL. Yeah, you have write some extra lines of code, but in return I get reliable tools, mature frameworks, simpler caching, easy to fine tune database queries, easy testability, etc.
[+] [-] bob1029|4 years ago|reply
Yes. I absolutely agree.
Start with a monolith. Use server-side rendering if possible. Use SQLite instead of [wretched nosql abomination]. API development is a waste of time. The business doesn't give a shit about any of this. Just make it work, then make it "webscale".
[+] [-] wsostt|4 years ago|reply
https://en.m.wikipedia.org/wiki/John_Gall_(author)
[+] [-] nuerow|4 years ago|reply
Doesn't this lead to an unnecessary increase in complexity without any immediate benefit?
> API development is a waste of time.
Why do you think so? Doesn't a well developed API mitigate, if not eliminate entirely, needless increases in complexity?
[+] [-] 29athrowaway|4 years ago|reply
Once you have reached at least junior level, start learning about how to split the system into subsystems and putting some additional thought into it.
The business doesn't give a shit about the implementation. Very true... that's why they hired you so that you fucking do. Just do your job.
If you want to work in finance, accounting, sales, investor relations, partnerships, business development or whatever, go do that. If you want to work creating software, start caring about how software is created, or at least don't ruin it for people that do.
If you decide to follow a business career path, you will find that they also have to care about their job, have attention to detail and care about good practices and compliance. In fact, that will also be the case for every occupation in every sector.
[+] [-] fc373745|4 years ago|reply
GQL notoriously performs weaker to REST in this regard.
>When a user navigates to a page on a web app or deep links into a Single Page Application (SPA) or a particular view in a mobile app, the frontend application needs to call the backend service to fetch the data needed to render the view. With RESTful APIs, it is unlikely that a single call will be able to get all the data. Typically, one call is made, then the frontend code iterates through the results of that call and makes more API calls per result item to get all the data needed.
>For example, I don’t want to navigate through multiple screens to review my travel itinerary; I want to see the summary (including flights, car rental, and hotel reservation) all on one screen before I commit to making the purchase.
I disagree.
Sure, sometimes more than one restful call is made for just one page, but the example given, when architectured properly is just a user foreign key relationship to all its children (reservations flights, rentals, etc), which is just a single sql query.
I don't think the author really understand the flexibility of REST and how much it can emulate what GQL has to offer.
If you want specificity in your query fetching, just add query params or put them in the request body
And if it is the case that you really do need resources from different endpoints, what is preventing you to build that single endpoint in REST?
[+] [-] pas|4 years ago|reply
Also, which properties of GQL make it inherently slower than REST ... ? Both are abstract concepts. (Also I'd argue that GQL is REST.)
[+] [-] Zababa|4 years ago|reply
If we assume that REST serves more requests than GraphQL, but GraphQL is more flexible, that may be a trade off of dev time of the application vs a dev time of the infrastructure. Which would fit with more and more people using orchestration and things like that. That might be a very wrong assumption though.
[+] [-] bob1029|4 years ago|reply
Performance is 99% about latency. And, when having this conversation, we are typically talking about I/O-bound latency.
Assume you have a trivial computer system that can only process 1 thing at a time. The number of things you can process per unit time is inversely proportional to the amount of time it takes to process each thing. Adding more threads/cores to the mix does not change this fundamental equation. Many practical business systems have a large component of processing that must occur in a serial fashion.
Think:
Multiple computers: Milliseconds, One computer: Nanoseconds
How much more work can you do if you can finish each unit in 100ns vs 5ms? How would this impact the user experience? Is the reason you cant finish in 100ns because you are doing global illumination on the CPU or because you are waiting for [hipster noSQL solution] to return some packets to your application server?
[+] [-] brightball|4 years ago|reply
You haven't supported your position that GraphQL is weaker at all. Everything that I have read, seen and heard is exactly the opposite. GraphQL seems to be the "I will never go back to REST" experience for virtually everybody I know in the field who has used it.
The other issue is that you're fighting the nature of REST itself to make it do more. Sure, you can make any API call take in specific input and send out exactly the output that you need...but REST API guidelines tend to preach exactly the opposite approach. The call should return one thing and if you want more, you need to get it yourself.
I'm open to hearing your perspective on this, but if you're going to make a claim like that you really need to support it.
[+] [-] mulkave|4 years ago|reply
[+] [-] shoo|4 years ago|reply
in some organisations the amount of meetings and overhead scales proportionally to the number of network connections in the architecture diagram, so that also suggests replacing external dependencies with in-process function calls wherever possible.
[+] [-] Cthulhu_|4 years ago|reply
[+] [-] nuerow|4 years ago|reply
Isn't this true for all software systems? If anything, microservice architectures just make it easier to re-architect parts of the system, thus lower the bar to actually do the work.
[+] [-] xyz11|4 years ago|reply
[+] [-] otar|4 years ago|reply
Systems grow from toddlers to old men, so do the businesses. They just evolve and adapt, otherwise they die.
[+] [-] 29athrowaway|4 years ago|reply
Your body is constantly "refactoring" itself via catabolic processes, and it's also getting of different forms of waste.
[+] [-] intellisense|4 years ago|reply
[+] [-] ngrilly|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] guru4consulting|4 years ago|reply