Business logic

29 views
Skip to first unread message

Matt Potter

unread,
Nov 20, 2020, 1:37:08 PM11/20/20
to Stargate Mailing List
Hello, 

Just came across this project and it looks really promising. I was wondering, where do you see the business logic layer living? I can see on your concepts page that you're connecting end clients directly to the Stargate APIs, e.g. gql, rest etc. But for apps that need additional logic before or around the persistence query, where would you see that living? Is that anything that's on the roadmap? My only thought at the moment is that I'd have to put another public facing GQL server in to hold my business logic, and then call the stargate APIs from that

Thanks!

Matt 

Denise Gosnell

unread,
Nov 23, 2020, 7:46:49 AM11/23/20
to Stargate Mailing List, Matt Potter
Matt,

Thank you for posting. I would love to hear more about what you are interested in creating because it depends.

If it’s not computationally heavy, I could see moving business logic into the client. Although if you have multiple different types of clients then that’s probably not ideal.

For graphql this is where stitching comes into play. Odds are if you’re already running graphql then you probably have other sources you’re hitting too so you could go client -> graphql -> stargate-gql

The only thing I am sure about is that we don’t want to get involved with pulling business logic into stargate. That’ll be a bad time for everyone involved. :)

WDYT?

We are chatting about this and other examples in our discord server. You (and all following this thread) are welcome to join us --> https://discord.gg/GravUqY

Cheers,

Denise

Matt Potter

unread,
Nov 23, 2020, 8:48:03 AM11/23/20
to Stargate Mailing List, denise....@datastax.com, Matt Potter
Hi Denise, 

Thanks for your reply! You're right about not bringing business logic into stargate, I don't suggest to effectively make stargate your entire backend :)  

I guess when evaluating Stargate I'm just trying to compare with what I think are the nearest equivalents, which are Hasura with Postgres and AWS Amplify/AppSync with its DynamoDB integrations. Those have remote resolvers/actions, where I could say execute a custom lambda function instead of just writing/reading straight to/from Dynamo, and as such are pretty fine to expose directly to clients because you can allow just raw read/write when appropriate, but trigger other actions where more logic is needed around the request. For example: if i have a createVideo(id: string) mutation that takes a s3 media path, maybe I'd like to: check that the user is on the correct paid plan, read some metadata from the file and then add the path to a job queue before returning a response.

This is what prompted my post, because your concepts page shows end users connecting directly to stargate, so I was hoping to see how requirements like this would fit.

What I would love in a GQL solution is: 

- Schema first design, which I noticed is already on your github issues :)
- API generation which creates/exports types that I can reuse, for me Protobuf would be perfect
- Ability to annotate schema with, say, GRPC endpoints so I can say "for this query/mutation, don't talk directly to cassandra, run this instead", and I implement using the protos generated above and can pass back the service definition to Stargate for it to generate a client

Thanks again, and I'm really interested to see where Stargate goes! 

Denise Gosnell

unread,
Nov 24, 2020, 9:14:16 AM11/24/20
to Matt Potter, Stargate Mailing List
Matt,

Cool, glad we are on the same page about biz logic. :)

Your comparisons to AWS App Sync are right on.  AWS AppSync is like a Data Gateway layer -- although it supports only GraphQL at the moment.

And, thank you for the requests for the next GraphQL implementation. We are quickly moving towards the next version of GQL which we hope to incorporate the features you described here. Come join our discussion in discord as we design this together -- https://discord.gg/33mKDHHFUE

We appreciate your posts; thank you for your interest!

Cheers,

Denise

--
Reply all
Reply to author
Forward
0 new messages