16 ms·

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, inclu

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about structuring REST calls but those aren't going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes. There are so many developers out there that can't stand plugging in proven solutions to problems and just dealing with the trade-offs or minor inconveniences. Nothing is going to be perfect and most likely a lot of the software we write will cease to be running in a decade.

aaronbrethorst 2y ago
Harder to get a promotion when you’re doing something that’s old, boring, and just works.
- suzzer99 2y ago
  Especially if your job title has "architect" in it.
- apantel 2y ago
  The closer you are to the cutting edge, the more sliced up you’re gonna get.
hansonkd 2y ago
REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions about structuring REST calls but those aren't going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes. You could argue almost any tech solution in a non-pure tech play is largely in consequentially as long as the end goal of the org is met, but managing REST APIS were a huge point of friction at past companies. Either it goes through a long review process to make sure things are structured "right" (ie lots of opinions that nobody can sync on) or people just throw up rest endpoints willynilly until you have no idea what to use. GraphQL is essentially the "Black" for Python Syntax but for Web APIs. Ever seen engineers fight over spaces vs tabs, 8 vs 4 spaces, whether a space before a colon? those fights happened a lot and then `black` came out and standardized it so there was nothing to fight over. GraphqL makes things very clear and standard, but can't please everyone.
- ComputerGuru 2y ago
  > With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.
  - hansonkd 2y ago
    Its gross because it is a waste. An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.
    - clintonb11 2y ago
      Is the flexibility worth the tradeoffs? Maybe in a company where you are adding new pages all the time with deeply nested relational data needs. But I would argue this is more rare than not. And I often find that frontend engineers aren’t as familiar with database queries and the load they are putting on the system with some of the graphql queries they are making. Flexibility for frontend has its own tradeoffs and I totally understand why a frontend engineer doesn’t want to have to wait for an endpoint to be finished. But this article outlines some of the issues you encounter later as you scale your team and system. We use a schema first design where I am at and if a frontend person needs a new endpoint because the resource-only endpoints aren’t enough then they submit a pull request to the schema repo with a design for their endpoint they need. It gets approved and boilerplate is auto generated. Yes you have to wait longer, but 90% of the time (for our software) the resource endpoints work great.
      - hansonkd 2y ago
        Sorry what are the tradeoffs? I'm not sure where this narrative comes from that GraphQL immediately means that the frontend time will have no idea what they are doing and will induce load on the system. 95% of my nested graphql fields are based on foreign key indexes so its almost no additional load to the system (only 1 query per "level" of GraphQL) to query the nested objects. I restrict GraphQL to 5 levels and now I have 5 queries per API call instead of 5 Queries over 5 API calls. The backend team exposes the fields that they know are efficient to query. They can restrict the depth of the GraphQL, number of fields, etc.
TheSoftwareGuy 2y ago
I think us engineers have an inherent desire to try to innovate, and I think that is a good thing. Some problems will require a lot of wrong turns before finding the right path, but that is simply the nature of innovation
- nurple 2y ago
  Agreed it's a good thing. Writing software today is still a slog that turns into a spaghetti bowl without focused intent by highly skilled devs. I think most devs realize this and really want there to be something better, and the only way to find something good is to find a lot of the bad around it first. I like the thought experiment of adding a new persisted/editable field to an entity in a web app, if you've done full-stack you know all the layers that need to be touched to accomplish this and how lame most of the work turns out to be. After doing that 20 times while iterating, any dev worth their salt starts to wonder why it sucks so bad still and how it could be made better, and some will actually try.
raxxorraxor 2y ago
XML still has its usage and is excellent to quickly validate documents, but JSON clearly won in this use case because it was kept simple, stupid.
cess11 2y ago
JSON winning over XML is like saying CSV won over MySQL. They aren't equivalent. Much like CSV, JSON isn't particularly standardised and different parsers and writers will do different things in some situations. Usually it doesn't matter, but when it does you're probably in for a lot of pain. If you handle structured data and the structures might change over time, JSON isn't a good fit. Maybe you'll opt for JSON Schema, maybe that'll work for your use case, but with XML you can be quite sure it'll be reliable and well understood by generations of developers. The tooling is generally very good, commonly you can just point your programming language to the XSD and suddenly you have statically typed classes to program against. Perhaps you'd like to store the data in a RDBMS? You can probably generate the DB schema from the XSD. If you want you can just throw JSON into MongoDB instead, but there will be very important tradeoffs. Same goes for UI, you can write some XSLT based on the XML schema and suddenly you get web views directly from API responses. Or you could use those classes you generated and have your GUI code consume such objects. None of this is as easy with JSON as it is with XML, similar to how many things aren't as easy with CSV as with a RDBMS.
- svachalek 2y ago
  What's missing in ECMA-404? Never had a problem with JSON parsers or writers, using it all day every day for decades. It's crappy in some ways, sure, like lack of full floating point support, but standardization is not an issue. XML is mostly already lost on the current generation of developers though, much less future developers. Protobuf and cousins generally do typed interchange more efficiently with less complexity.
  - WorldMaker 2y ago
    There are a lot of proponents that some or all of the "JSON5" [1] improvements should be standardized by ECMA as well. Especially because there is a mish-mash of support for such things in some but not all parsers. (Writers are a different matter.) Primarily comments and trailing commas, are huge wish list items and the biggest reasons for all of the other "many" variant parsers (JSONC, etc). [1] https://json5.org/ https://json5.org/
LeonenTheDK 2y ago
> and most likely a lot of the software we write will cease to be running in a decade If only that were true in my experience.
solidasparagus 2y ago
I think IDLs and gRPC in particular are a meaningful advancement in the problem space. The ecosystem and productivity that they enable via programatic tooling were really eye-opening for me (The OpenAPI ecosystem is, imo, extremely poor). They also have better support for modern techniques like streaming and even load-balanced streaming.
- tormeh 2y ago
  Amen, brother! gRPC is the best thing since sliced bread. Typed APIs are just so nice to work with, and OpenAPI is very unsatisfactory.

aaronbrethorst 2y ago

Harder to get a promotion when you’re doing something that’s old, boring, and just works.

suzzer99 2y ago
Especially if your job title has "architect" in it.
apantel 2y ago
The closer you are to the cutting edge, the more sliced up you’re gonna get.

hansonkd 2y ago

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions about structuring REST calls but those aren't going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes. You could argue almost any tech solution in a non-pure tech play is largely in consequentially as long as the end goal of the org is met, but managing REST APIS were a huge point of friction at past companies. Either it goes through a long review process to make sure things are structured "right" (ie lots of opinions that nobody can sync on) or people just throw up rest endpoints willynilly until you have no idea what to use. GraphQL is essentially the "Black" for Python Syntax but for Web APIs. Ever seen engineers fight over spaces vs tabs, 8 vs 4 spaces, whether a space before a colon? those fights happened a lot and then `black` came out and standardized it so there was nothing to fight over. GraphqL makes things very clear and standard, but can't please everyone.

ComputerGuru 2y ago
> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.
- hansonkd 2y ago
  Its gross because it is a waste. An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.
  - clintonb11 2y ago
    Is the flexibility worth the tradeoffs? Maybe in a company where you are adding new pages all the time with deeply nested relational data needs. But I would argue this is more rare than not. And I often find that frontend engineers aren’t as familiar with database queries and the load they are putting on the system with some of the graphql queries they are making. Flexibility for frontend has its own tradeoffs and I totally understand why a frontend engineer doesn’t want to have to wait for an endpoint to be finished. But this article outlines some of the issues you encounter later as you scale your team and system. We use a schema first design where I am at and if a frontend person needs a new endpoint because the resource-only endpoints aren’t enough then they submit a pull request to the schema repo with a design for their endpoint they need. It gets approved and boilerplate is auto generated. Yes you have to wait longer, but 90% of the time (for our software) the resource endpoints work great.
    - hansonkd 2y ago
      Sorry what are the tradeoffs? I'm not sure where this narrative comes from that GraphQL immediately means that the frontend time will have no idea what they are doing and will induce load on the system. 95% of my nested graphql fields are based on foreign key indexes so its almost no additional load to the system (only 1 query per "level" of GraphQL) to query the nested objects. I restrict GraphQL to 5 levels and now I have 5 queries per API call instead of 5 Queries over 5 API calls. The backend team exposes the fields that they know are efficient to query. They can restrict the depth of the GraphQL, number of fields, etc.

TheSoftwareGuy 2y ago

I think us engineers have an inherent desire to try to innovate, and I think that is a good thing. Some problems will require a lot of wrong turns before finding the right path, but that is simply the nature of innovation

nurple 2y ago
Agreed it's a good thing. Writing software today is still a slog that turns into a spaghetti bowl without focused intent by highly skilled devs. I think most devs realize this and really want there to be something better, and the only way to find something good is to find a lot of the bad around it first. I like the thought experiment of adding a new persisted/editable field to an entity in a web app, if you've done full-stack you know all the layers that need to be touched to accomplish this and how lame most of the work turns out to be. After doing that 20 times while iterating, any dev worth their salt starts to wonder why it sucks so bad still and how it could be made better, and some will actually try.

raxxorraxor 2y ago

XML still has its usage and is excellent to quickly validate documents, but JSON clearly won in this use case because it was kept simple, stupid.

cess11 2y ago

JSON winning over XML is like saying CSV won over MySQL. They aren't equivalent. Much like CSV, JSON isn't particularly standardised and different parsers and writers will do different things in some situations. Usually it doesn't matter, but when it does you're probably in for a lot of pain. If you handle structured data and the structures might change over time, JSON isn't a good fit. Maybe you'll opt for JSON Schema, maybe that'll work for your use case, but with XML you can be quite sure it'll be reliable and well understood by generations of developers. The tooling is generally very good, commonly you can just point your programming language to the XSD and suddenly you have statically typed classes to program against. Perhaps you'd like to store the data in a RDBMS? You can probably generate the DB schema from the XSD. If you want you can just throw JSON into MongoDB instead, but there will be very important tradeoffs. Same goes for UI, you can write some XSLT based on the XML schema and suddenly you get web views directly from API responses. Or you could use those classes you generated and have your GUI code consume such objects. None of this is as easy with JSON as it is with XML, similar to how many things aren't as easy with CSV as with a RDBMS.

svachalek 2y ago
What's missing in ECMA-404? Never had a problem with JSON parsers or writers, using it all day every day for decades. It's crappy in some ways, sure, like lack of full floating point support, but standardization is not an issue. XML is mostly already lost on the current generation of developers though, much less future developers. Protobuf and cousins generally do typed interchange more efficiently with less complexity.
- WorldMaker 2y ago
  There are a lot of proponents that some or all of the "JSON5" [1] improvements should be standardized by ECMA as well. Especially because there is a mish-mash of support for such things in some but not all parsers. (Writers are a different matter.) Primarily comments and trailing commas, are huge wish list items and the biggest reasons for all of the other "many" variant parsers (JSONC, etc). [1] https://json5.org/ https://json5.org/

LeonenTheDK 2y ago

> and most likely a lot of the software we write will cease to be running in a decade If only that were true in my experience.

solidasparagus 2y ago

I think IDLs and gRPC in particular are a meaningful advancement in the problem space. The ecosystem and productivity that they enable via programatic tooling were really eye-opening for me (The OpenAPI ecosystem is, imo, extremely poor). They also have better support for modern techniques like streaming and even load-balanced streaming.

tormeh 2y ago
Amen, brother! gRPC is the best thing since sliced bread. Typed APIs are just so nice to work with, and OpenAPI is very unsatisfactory.