6 ms·

I've used GraphQL on several projects now, with small teams (2-5 devs) where we control the front and back end, and for that case, it's actually been really goo

by vlunkr 4y ago

I've used GraphQL on several projects now, with small teams (2-5 devs) where we control the front and back end, and for that case, it's actually been really good. It provides a solid contract that is easy to get wrong with a REST API. (Will the server send IDs as ints or strings? Will it accept either? Which params are optional? What shape does the data come back in, an array of results, or an objects with results nested somewhere? etc.) I've even setup CI to fail if it finds queries on the front-end that don't match the schema. And of course it's easy to request exactly the data you want on the front -end. A big downside is that the tooling is immature, and all subject to big changes. And I haven't written a server meant for public consumption, but that does add new layers that you can kind of ignore when you trust the client.

rizzaxc 4y ago
why is protobuf not an option to you?
marcosdumay 4y ago
> Will the server send IDs as ints or strings? Will it accept either? Which params are optional? What shape does the data come back in, an array of results, or an objects with results nested somewhere? etc. Hum... It seems you are missing a data definition language. GraphQL isn't a very good solution to that.
- mikewhy 4y ago
  Graphql literally forces you to define a schema and adhere to it.
  - CRConrad 4y ago
    So does SQL.
    - vlunkr 4y ago
      Sure, but you're not writing SQL queries on the front end.
      - CRConrad 4y ago
        That's the problem -- you should be! ;-)
    - mikewhy 4y ago
      You're aware GraphQL isn't limited to calling out to SQL databases, right?
waynesonfire 4y ago
If you own the backend and the frontend, I don't see how graphql helps you. You can just implement the APIs that you need to solve your business problems. Now all you're left with are the downsides. I'll pass.
- vlunkr 4y ago
  I listed some ways that it helps. You get a strict, well-defined, easily-documented API. Yeah, you can do all that with REST, but I like having a defined structure for it.
  - jsiaajdsdaa 4y ago
    What happens if it breaks, and now you have to debug a framework/library instead of your own code?
    - chillacy 4y ago
      On a large team I’ll often be debugging someone else’s code anyways, and the framework code is usually better than hacked together product code (and comes with a public bug tracker).
      - jsiaajdsdaa 4y ago
        On the team I lead, we keep our domain logic pure, encapsulated, and layered. This means that if I have to debug a fellow teammates code, I can be confident that it is only business logic related code and not more technical, library dependent code. When our code has to interact with other systems, the other systems' responses have to pass through an anti corruption layer and be translated into something we care about. All of this is surrounded with try catch and we quite obsessively check and validate everything coming in and out. We do all of this because if/when something breaks in some library or framework that we didnt write, it doesnt bleed through to our POJOs. And, if we ever need to switch to the new flavor of the week library which happens quite often, we don't have to rewrite everything, just the adapter classes.
  - 4y ago
RustyRussell 4y ago
I use JSON schema for this, by integrating it into our CI so it checks all the JSONRPC calls and responses. (Helps that our test suite is in Python, which has great JSON schema support).
shroompasta 4y ago
I don't understand how if you're on a team in which you control both the front end and back end, you wouldn't understand these factors - "Will the server send IDs as ints or strings? Will it accept either? Which params are optional? What shape does the data come back in, an array of results, or an objects with results nested somewhere? etc" Surely you would know all the answers to these questions because your team control the entire stack. If it was the case that the FE and BE teams were separate, then these would be reasonable considerations, but I just don't see it in a team dealing with full control.
- digitxpc 4y ago
  Designing a solid contract can be useful even when you’re one person, for the same reason that decoupling classes or concerns is useful. I don’t need to consult another person or read the code to understand what it’s expecting (especially true in contexts where documentation may not have been written yet).

by vlunkr 4y ago

rizzaxc 4y ago

why is protobuf not an option to you?

marcosdumay 4y ago

> Will the server send IDs as ints or strings? Will it accept either? Which params are optional? What shape does the data come back in, an array of results, or an objects with results nested somewhere? etc. Hum... It seems you are missing a data definition language. GraphQL isn't a very good solution to that.

mikewhy 4y ago
Graphql literally forces you to define a schema and adhere to it.
- CRConrad 4y ago
  So does SQL.
  - vlunkr 4y ago
    Sure, but you're not writing SQL queries on the front end.
    - CRConrad 4y ago
      That's the problem -- you should be! ;-)
  - mikewhy 4y ago
    You're aware GraphQL isn't limited to calling out to SQL databases, right?

waynesonfire 4y ago

If you own the backend and the frontend, I don't see how graphql helps you. You can just implement the APIs that you need to solve your business problems. Now all you're left with are the downsides. I'll pass.

vlunkr 4y ago
I listed some ways that it helps. You get a strict, well-defined, easily-documented API. Yeah, you can do all that with REST, but I like having a defined structure for it.
- jsiaajdsdaa 4y ago
  What happens if it breaks, and now you have to debug a framework/library instead of your own code?
  - chillacy 4y ago
    On a large team I’ll often be debugging someone else’s code anyways, and the framework code is usually better than hacked together product code (and comes with a public bug tracker).
    - jsiaajdsdaa 4y ago
      On the team I lead, we keep our domain logic pure, encapsulated, and layered. This means that if I have to debug a fellow teammates code, I can be confident that it is only business logic related code and not more technical, library dependent code. When our code has to interact with other systems, the other systems' responses have to pass through an anti corruption layer and be translated into something we care about. All of this is surrounded with try catch and we quite obsessively check and validate everything coming in and out. We do all of this because if/when something breaks in some library or framework that we didnt write, it doesnt bleed through to our POJOs. And, if we ever need to switch to the new flavor of the week library which happens quite often, we don't have to rewrite everything, just the adapter classes.
- 4y ago

RustyRussell 4y ago

I use JSON schema for this, by integrating it into our CI so it checks all the JSONRPC calls and responses. (Helps that our test suite is in Python, which has great JSON schema support).

shroompasta 4y ago

I don't understand how if you're on a team in which you control both the front end and back end, you wouldn't understand these factors - "Will the server send IDs as ints or strings? Will it accept either? Which params are optional? What shape does the data come back in, an array of results, or an objects with results nested somewhere? etc" Surely you would know all the answers to these questions because your team control the entire stack. If it was the case that the FE and BE teams were separate, then these would be reasonable considerations, but I just don't see it in a team dealing with full control.

digitxpc 4y ago
Designing a solid contract can be useful even when you’re one person, for the same reason that decoupling classes or concerns is useful. I don’t need to consult another person or read the code to understand what it’s expecting (especially true in contexts where documentation may not have been written yet).