5 ms·

What are you moving to as an alternative?

by pspeter3 9y ago

pier25 9y ago
I'm not the author, but I moved back to good old REST after flirting a bit with GraphQL.
- pspeter3 9y ago
  What was your decision for REST over GraphQL?
  - pier25 9y ago
    GraphQL requires you to know upfront what you want to receive. You can't for example receive data for a menu with submenus with undetermined level of depth. You can hack your way around the problem, but it's ugly. Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company?
    - maktouch 9y ago
      > Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company? http://graphql.org/learn/schema/#interfaces http://graphql.org/learn/schema/#interfaces searchPersonOrCompany(name: "abc") { ... on User { first_name last_name } ... on Company { business_name } } As for the undetermined depths problem -- I agree to an extent. GraphQL can't return depths without you querying for it unless one of the field is a JSON blob.. but at the same time, I like that it does that. In your example of menu w/ submenus, I think I would prefer to load the first 2 level, then preload level 3 when level 2 is activated, and preload level 5 when level 4 is activated, and so on. Apollo makes this quite easy.
      - penagwin 9y ago
        Are you saying to request each level as needed? That's a lot of round trips, especially if levels need to be opened on mouseover or something.
        sorenbs 9y ago
        Nah, just query for as many levels as you think you might need up front.
      - pier25 9y ago
        Well today I learned a couple things. Thanks for the example and ideas.
    - dankent 9y ago
      If I want to get all levels of an arbitrarily nested tree, I just query for all of the objects that are in the tree in a flat array and then reconstruct the tree on the client side using the parent/child Ids. This is similar to what I would have to do server side if I were using SQL to get the data and then processing it to return a tree in JSON. If I know how deep the tree will be (and it is only two or three levels) I query it directly with graphql
- mluggy 9y ago
  hi guys, OP here. updated the post with my current stack (it is everything but fancy)
- dankent 9y ago
  I've been using graphql recently and I have found it very productive. Providing a lot of flexibility to the client when querying the server eliminates a lot of server side work that would normally be required in order to implement new user stories. It does require a bit of a mindset change so I am often having to force myself to try doing things in a different way to my first assumption.
tootie 9y ago
I think AWS is the all-purpose fallback. It has some turnkey solutions for some problems of various quality, but you can always just use EC2 with custom code. S3 is a miraculous product. Lambdas are pretty cool. You can try your hand with DynamoDB, but RDS is there for you too. There's generally much less lock-in.
- pspeter3 9y ago
  I've thought about Cloud Functions but Lambda may be better.
unoti 9y ago
I'm moving to a combination of 2 things: [1] Cosmos DB for data storage, and [2] Service Fabric for the things that require real-time collaborative logic. An example of what I mean by #2 is things like real-time discussions where content pops in dynamically. The big problem for me using a serverless architecture was constantly having to bend over backwards with the security model of firebase to accomplish things that are very simple when you have a layer of business logic under your own control on the server between the client and the database. Once the client can write whatever they want to the database, every single operation becomes an order of magnitude more difficult to develop as you imagine what ways the client could mess with you, and develop security rules to prevent that. The result-- and this was the dealbreaker for me-- is designing the backend data structure around security, instead of designing the backend data structure around the vitally important goal of supporting your business use cases. In the end I decided it's better to just pony up and make a server. Service Fabric, and particularly the distributed actor model, gives me the realtime functions and reliability I want for my use cases without making me administer servers. [1] https://docs.microsoft.com/en-us/azure/cosmos-db/introduction https://docs.microsoft.com/en-us/azure/cosmos-db/introductio... [2] https://azure.microsoft.com/en-us/services/service-fabric/ https://azure.microsoft.com/en-us/services/service-fabric/
- WalterSear 9y ago
  I'm afraid I don't yet follow your problem: what's hard about having a function listen for a change in the db, performing the business logic, and updating another value?
  - unoti 9y ago
    I need to segment the db into two sections: a section the client can update, and another section that only the protected business logic can update. It's doable, but more difficult than the traditional setup. Also when I started this project functions weren't available-- that happened in March of this year. Initially I used a machine elsewhere in my infrastructure to do this work of watching for the changes then writing to the restricted access areas.

What are you moving to as an alternative?

pier25 9y ago

I'm not the author, but I moved back to good old REST after flirting a bit with GraphQL.

pspeter3 9y ago
What was your decision for REST over GraphQL?
- pier25 9y ago
  GraphQL requires you to know upfront what you want to receive. You can't for example receive data for a menu with submenus with undetermined level of depth. You can hack your way around the problem, but it's ugly. Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company?
  - maktouch 9y ago
    > Another problem GraphQL hasn't tackled (afaik) is polymorphism. You can say "hey give me this person" or "give me this company", but what if you want a customer that can be either a person or a company? http://graphql.org/learn/schema/#interfaces http://graphql.org/learn/schema/#interfaces searchPersonOrCompany(name: "abc") { ... on User { first_name last_name } ... on Company { business_name } } As for the undetermined depths problem -- I agree to an extent. GraphQL can't return depths without you querying for it unless one of the field is a JSON blob.. but at the same time, I like that it does that. In your example of menu w/ submenus, I think I would prefer to load the first 2 level, then preload level 3 when level 2 is activated, and preload level 5 when level 4 is activated, and so on. Apollo makes this quite easy.
    - penagwin 9y ago
      Are you saying to request each level as needed? That's a lot of round trips, especially if levels need to be opened on mouseover or something.
      - sorenbs 9y ago
        Nah, just query for as many levels as you think you might need up front.
    - pier25 9y ago
      Well today I learned a couple things. Thanks for the example and ideas.
  - dankent 9y ago
    If I want to get all levels of an arbitrarily nested tree, I just query for all of the objects that are in the tree in a flat array and then reconstruct the tree on the client side using the parent/child Ids. This is similar to what I would have to do server side if I were using SQL to get the data and then processing it to return a tree in JSON. If I know how deep the tree will be (and it is only two or three levels) I query it directly with graphql
mluggy 9y ago
hi guys, OP here. updated the post with my current stack (it is everything but fancy)
dankent 9y ago
I've been using graphql recently and I have found it very productive. Providing a lot of flexibility to the client when querying the server eliminates a lot of server side work that would normally be required in order to implement new user stories. It does require a bit of a mindset change so I am often having to force myself to try doing things in a different way to my first assumption.

tootie 9y ago

I think AWS is the all-purpose fallback. It has some turnkey solutions for some problems of various quality, but you can always just use EC2 with custom code. S3 is a miraculous product. Lambdas are pretty cool. You can try your hand with DynamoDB, but RDS is there for you too. There's generally much less lock-in.

pspeter3 9y ago
I've thought about Cloud Functions but Lambda may be better.

unoti 9y ago

I'm moving to a combination of 2 things: [1] Cosmos DB for data storage, and [2] Service Fabric for the things that require real-time collaborative logic. An example of what I mean by #2 is things like real-time discussions where content pops in dynamically. The big problem for me using a serverless architecture was constantly having to bend over backwards with the security model of firebase to accomplish things that are very simple when you have a layer of business logic under your own control on the server between the client and the database. Once the client can write whatever they want to the database, every single operation becomes an order of magnitude more difficult to develop as you imagine what ways the client could mess with you, and develop security rules to prevent that. The result-- and this was the dealbreaker for me-- is designing the backend data structure around security, instead of designing the backend data structure around the vitally important goal of supporting your business use cases. In the end I decided it's better to just pony up and make a server. Service Fabric, and particularly the distributed actor model, gives me the realtime functions and reliability I want for my use cases without making me administer servers. [1] https://docs.microsoft.com/en-us/azure/cosmos-db/introduction https://docs.microsoft.com/en-us/azure/cosmos-db/introductio... [2] https://azure.microsoft.com/en-us/services/service-fabric/ https://azure.microsoft.com/en-us/services/service-fabric/

WalterSear 9y ago
I'm afraid I don't yet follow your problem: what's hard about having a function listen for a change in the db, performing the business logic, and updating another value?
- unoti 9y ago
  I need to segment the db into two sections: a section the client can update, and another section that only the protected business logic can update. It's doable, but more difficult than the traditional setup. Also when I started this project functions weren't available-- that happened in March of this year. Initially I used a machine elsewhere in my infrastructure to do this work of watching for the changes then writing to the restricted access areas.