4 ms·

Having worked a long time with client teams as a lead - this is always the biggest pain in the ass. At one of my last phase startups I started shifting all our

Having worked a long time with client teams as a lead - this is always the biggest pain in the ass. At one of my last phase startups I started shifting all our business logic stuff into our graphql server and treated it like it was part of the client teams. (we had ios/android/web as independent full apps with a very small team of devs). Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy. Send down viewmodels to the clients not data models. etc etc. This helped DRAMATICALLY with complexity in the clients.

weird-eye-issue 1y ago
So your takeaway is that business logic should be done on the server. Hasn't it always been like this?
- hbbio 1y ago
  Has been the true core vision of the web if not mobile. If I remember correctly, that is how the original Basecamp was implemented, or Craigslist (still is?)... or this very website
  - weird-eye-issue 1y ago
    Also I just realized the irony of them using GraphQL. They've really come full circle
- sunnybeetroot 1y ago
  OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.
  - weird-eye-issue 1y ago
    Your API should be fast enough and hosted on the edge so that the server side validation is instant feedback
    - sunnybeetroot 1y ago
      There are external factors apart from your own API that can impact latency, for example a user could be in an area of poor internet connection or have a slow connection. Users do not live in our perfect development environment bubble where everything just works, it’s important not to assume that.
      - weird-eye-issue 1y ago
        If it takes 1 second for a small percent of users to get form validation back it won't impact the business
        chrisandchris 1y ago
        That's how we got to "download 50 GB before playing a game on a console is fine", feels like we just stopped carying. Sending the form to the BE just to do same basic validation adds so much latency to the UI that it feel unusable for many/most users. Related: A few Sundays ago I wanted to play Anno again. Sadly it was not installed on the Laptop I used. So i started downloding it because you won't get it on DVD/as iso-file today). Now it's a few Sundays after and I didn't play yet - because the download took 7 hours.
        weird-eye-issue 1y ago
        That's such a ridiculous logical falacy. You already have to send the form input to submit the form in the first place and you already need server side validation. I just checked one of my app's register page (which makes > $2M ARR). If you submit a short password it returns an error from the backend that says "Password should be at least 6 characters.". (It uses Supabase). But yeah, that is so unusable it is basically the same as taking 7 hours to download a game onto your Playstation. Great logic!
noduerme 1y ago
I guess I'm not clear on what you mean about putting business logic in the client. It can't only be on the client side. If you do so, then obviously you have to replicate it on the server to check that the client was sending the right results, no? Not to mention avoiding thread races and double inserts and whatever else may have gone stale on the server before you allow a client to validate something? Even if your code isn't public-facing, the server still needs to check everything. As a solo dev it seems insane to me to ever put business logic in the client, unless the client and server literally share the same typescript codebase for crosschecking ops, and even then the server needs the same code plus additional safeguards. It baffles me that anyone would write a platform from the ground up with primary business logic on the client side, if the server isn't written in the same language. Maybe some simple initial validations and checks to avoid bombarding the server, but the server has to be the central source of truth.
- throwup238 1y ago
  That’s the exact opposite of what the GP is suggesting. Read this again: > Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy. Move the logic to the GQL retriever so that clients don’t have to implement business logic.
  - noduerme 1y ago
    Yeah, I understood what they said. I'm wondering why the previous owners of the code decided to put business logic in the client.
    - virtue3 1y ago
      we had a lot of very talented iOS devs that started running away with feature development when the server team couldn't keep up. This really hurt the android + web client teams. Eventually our backend started changing (mono-rail -> microservices) and it turned into an absolute cluster of trying to massage/cram new data models into the existing ones the iOS team created. Late stage startup and then post finding product market fit problems.
forgotusername6 1y ago
What if you want your app to work offline?
- fragmede 1y ago
  And not just off-line, but as we learned last week, if us–east-1 is down you have spotty connectivity, not hard down, and your device needs to not cook your users; literally in the case of Sleep8.
  - abustamam 1y ago
    We've really hit a strange level of dystopia when your bed doesn't work because a server is down
    - inquirerGeneral 1y ago
      [dead]
- virtue3 1y ago
  It was a near real-time messaging application. So not really applicable (other than seeing messages you already received - which could be cached from previous sessions).

weird-eye-issue 1y ago

So your takeaway is that business logic should be done on the server. Hasn't it always been like this?

hbbio 1y ago
Has been the true core vision of the web if not mobile. If I remember correctly, that is how the original Basecamp was implemented, or Craigslist (still is?)... or this very website
- weird-eye-issue 1y ago
  Also I just realized the irony of them using GraphQL. They've really come full circle
sunnybeetroot 1y ago
OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.
- weird-eye-issue 1y ago
  Your API should be fast enough and hosted on the edge so that the server side validation is instant feedback
  - sunnybeetroot 1y ago
    There are external factors apart from your own API that can impact latency, for example a user could be in an area of poor internet connection or have a slow connection. Users do not live in our perfect development environment bubble where everything just works, it’s important not to assume that.
    - weird-eye-issue 1y ago
      If it takes 1 second for a small percent of users to get form validation back it won't impact the business
      - chrisandchris 1y ago
        That's how we got to "download 50 GB before playing a game on a console is fine", feels like we just stopped carying. Sending the form to the BE just to do same basic validation adds so much latency to the UI that it feel unusable for many/most users. Related: A few Sundays ago I wanted to play Anno again. Sadly it was not installed on the Laptop I used. So i started downloding it because you won't get it on DVD/as iso-file today). Now it's a few Sundays after and I didn't play yet - because the download took 7 hours.
        weird-eye-issue 1y ago
        That's such a ridiculous logical falacy. You already have to send the form input to submit the form in the first place and you already need server side validation. I just checked one of my app's register page (which makes > $2M ARR). If you submit a short password it returns an error from the backend that says "Password should be at least 6 characters.". (It uses Supabase). But yeah, that is so unusable it is basically the same as taking 7 hours to download a game onto your Playstation. Great logic!

noduerme 1y ago

I guess I'm not clear on what you mean about putting business logic in the client. It can't only be on the client side. If you do so, then obviously you have to replicate it on the server to check that the client was sending the right results, no? Not to mention avoiding thread races and double inserts and whatever else may have gone stale on the server before you allow a client to validate something? Even if your code isn't public-facing, the server still needs to check everything. As a solo dev it seems insane to me to ever put business logic in the client, unless the client and server literally share the same typescript codebase for crosschecking ops, and even then the server needs the same code plus additional safeguards. It baffles me that anyone would write a platform from the ground up with primary business logic on the client side, if the server isn't written in the same language. Maybe some simple initial validations and checks to avoid bombarding the server, but the server has to be the central source of truth.

throwup238 1y ago
That’s the exact opposite of what the GP is suggesting. Read this again: > Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy. Move the logic to the GQL retriever so that clients don’t have to implement business logic.
- noduerme 1y ago
  Yeah, I understood what they said. I'm wondering why the previous owners of the code decided to put business logic in the client.
  - virtue3 1y ago
    we had a lot of very talented iOS devs that started running away with feature development when the server team couldn't keep up. This really hurt the android + web client teams. Eventually our backend started changing (mono-rail -> microservices) and it turned into an absolute cluster of trying to massage/cram new data models into the existing ones the iOS team created. Late stage startup and then post finding product market fit problems.

forgotusername6 1y ago

What if you want your app to work offline?

fragmede 1y ago
And not just off-line, but as we learned last week, if us–east-1 is down you have spotty connectivity, not hard down, and your device needs to not cook your users; literally in the case of Sleep8.
- abustamam 1y ago
  We've really hit a strange level of dystopia when your bed doesn't work because a server is down
  - inquirerGeneral 1y ago
    [dead]
virtue3 1y ago
It was a near real-time messaging application. So not really applicable (other than seeing messages you already received - which could be cached from previous sessions).