4 ms·

Given the complex services we already have, services that access complex, multi-source databases of the relational and NoSQL kind, I find it amusing that UI dev

Given the complex services we already have, services that access complex, multi-source databases of the relational and NoSQL kind, I find it amusing that UI developers are so unaware of the complexities of the back end--complexities that are normally hidden from them--that they think they can be reduced to so many calls. WebSockets don't magically assemble complex back-end data. Amusing in the extreme.

douche 10y ago
It's the classic "Can't you just add another checkbox here?" situation. Yes, I can add a checkbox there. But I have to add the code to include that setting in the API that the front-end calls, to give you a way to retrieve it and change it. Then I have to add code to the data access layer for this new setting. Then I have to write the SQL scripts to add columns/tables for this new setting, as well as change scripts to change the schema. Then I have to test all the pieces involved, test that upgrading the database from N-3 recent releases to the new schema works correctly. And this is for a dead simple little setting.
- caseymarquis 10y ago
  Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel <==> db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you aren't also doing the frontend, tell the guy who is to check out the updated swagger docs.
  - douche 10y ago
    Our framework does kind of suck... We're also not doing the common website/webapp thing, but rather on-premise enterprise software. So we have to update installers too, and be relatively paranoid about updates, because it is intensely painful when we have a bad update with one of our customers.
    - caseymarquis 10y ago
      I feel that. We have the same deployment model and customers pay hundreds of thousands of dollars to have our systems installed. When our systems go down individual companies can lose tens of thousands of dollars in an hour. More than that under some circumstances. We always test migrations thoroughly on those systems. Even simple ones. On our less important software that'd just be a direct push to production though.
  - nahname 10y ago
    So simple anyone with at least three to five years experience and 4 months on the project can do it! Starting salary is 120k, relo to SF required.
  - grosbisou 10y ago
    > cause it's just adding a column This kind of mentality is why most applications are shit and broken. And why most hires are worthless. And everyone is not working on a cookie cutter over-bloated rails website. Sorry but this kind of remark simplifying our job always pisses me off.
    - prplhaz4 10y ago
      "can't we just" is top of the list as a trigger for my bullshit detector. In a system of any complexity, changing your data model is an activity that requires due diligence to mitigate any downstream risk.
      - collyw 10y ago
        Me too. When my previous team leader said that, I knew he hadn't bothered to think it through.
    - caseymarquis 10y ago
      At my company, we have one software package it costs on average a quarter million USD to install per enterprise customer. It gets about 100,000 records added per day in some deployments. We test our migrations on those systems and have a dedicated data service which is the only thing which can touch any given customer database. We are paranoid about those systems. We also have throwaway apps like an internal time clock system which monitors when people show up based on their cell MAC. Latter case: Adding a checkbox is easy. Former case: Adding a checkbox is easy but we have to test it first.
      - heartbreak 10y ago
        > which monitors when people show up based on their cell MAC That sounds miserable.
        caseymarquis 10y ago
        It's voluntary. We're all salary and a portion of our bonus is based on hours worked. When I did the occasional 100 hour week (also voluntary; I work on fun stuff) and forgot to log my hours, I would get credit for it, but there wasn't a direct metric for compensation. We started adding in other employees in multiple departments cause they liked it better than manually tracking.
  - krisdol 10y ago
    And that, my friends, is how the first company I worked at ended up with a Contact table of 972 columns.
  - arenaninja 10y ago
    If you're working on a database without any data in it, sure. When your tables have millions of records for enterprise customers, it's significantly more involved than you describe
  - sontek 10y ago
    This is definitely a common use case and very valid for smaller applications. If I were you though I would avoid applying your experience on smaller scale applications as a way to say that everyone who can't do that are using bad frameworks. Once your application reaches a certain scale there is a huge chance that generated migration could lock a table for minutes to hours which isn't acceptable. We allow developers to run generated migrations in dev/testing environments but when its time to go to staging we evaluate the changes made and check query plans and figure out what type of locking is going to happen and how long it would take it prod. There is very few times the migrations Django or Rails generate are acceptable at our scale in production.
    - caseymarquis 10y ago
      I think you're correct. I was out of line by being too general. For our large scale applications we back up the database and have required down time from our customers while doing a major migration. Everything isn't always simple. But adding a check box in 90% of cases usually is.
      - sontek 10y ago
        Adding a check box in a relational database most likely involves running ALTER TABLE to introduce a new column which in most relational databases locks the table. Now lets say you are doing 15,000 requests per second on that table.... is preventing those from executing acceptable in your system? Its not in mine which is why we don't run ORM generated migrations.
        caseymarquis 10y ago
        I conceed. For some databases, any adjustment is clearly a major decision with potential consequences. My comment was needlessly inflammatory.
  - nameless912 10y ago
    > Push to master. Update production. You monster. You fucking monster. The reality is that ORMs are a huge headache and a chunk of dependency and magic that make some people uncomfortable. Even though I make more mistakes writing the glue code between SQL and my backend than I would with the ORM, I know how every bit of that code works, and I've reduced significantly the magic I have to deal with in order for my code to work (basically, just the database driver since I own everything else). ORMs are a huge surface to secure, tune, and understand, and I think that it's unfair to tell someone their app sucks just because they refuse to use one.
    - caseymarquis 10y ago
      I didn't say his code was bad. I meant whatever they're using for libraries must be a pain to work with. I was overly general, should have used different language, and what I said was flat out wrong for some environments.
      - nameless912 10y ago
        I'm gald you acknowledge that! But seriously. Pushing to master, AND updating production...where are your unit tests!?!?
    - caseymarquis 10y ago
      I didn't say his code was bad. I meant whatever they're using for libraries must be a pain to work with. I was overly general, should have used different language, and what I said was flat out wrong for some environments.
- mattm 10y ago
  This reminds of I conversation I had with a mobile developer. He came up with a prototype to show to a client. The prototype was just interactive screenshots with nothing going on in the backend. After showing it to the client, the client was excited that the app was pretty much done. The developer explained that this was just a prototype and all the coding still needed to be done. The client couldn't understand and kept saying that it was basically done.
leecarraher 10y ago
i often get the, can we make this a websocket instead of an api call. that way it can just get updated instead of you having to run a query... 1. not neccessarily faster (push vs pull depends entirely on the data creation consumption model) 2. the push scenario is not how most database access patterns work. Instead it's likely just polling the db on the backend instead of the front end. So same db load. and now lots of open connections to simultaneously maintain and garbage collect.

douche 10y ago

It's the classic "Can't you just add another checkbox here?" situation. Yes, I can add a checkbox there. But I have to add the code to include that setting in the API that the front-end calls, to give you a way to retrieve it and change it. Then I have to add code to the data access layer for this new setting. Then I have to write the SQL scripts to add columns/tables for this new setting, as well as change scripts to change the schema. Then I have to test all the pieces involved, test that upgrading the database from N-3 recent releases to the new schema works correctly. And this is for a dead simple little setting.

caseymarquis 10y ago
Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel <==> db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you aren't also doing the frontend, tell the guy who is to check out the updated swagger docs.
- douche 10y ago
  Our framework does kind of suck... We're also not doing the common website/webapp thing, but rather on-premise enterprise software. So we have to update installers too, and be relatively paranoid about updates, because it is intensely painful when we have a bad update with one of our customers.
  - caseymarquis 10y ago
    I feel that. We have the same deployment model and customers pay hundreds of thousands of dollars to have our systems installed. When our systems go down individual companies can lose tens of thousands of dollars in an hour. More than that under some circumstances. We always test migrations thoroughly on those systems. Even simple ones. On our less important software that'd just be a direct push to production though.
- nahname 10y ago
  So simple anyone with at least three to five years experience and 4 months on the project can do it! Starting salary is 120k, relo to SF required.
- grosbisou 10y ago
  > cause it's just adding a column This kind of mentality is why most applications are shit and broken. And why most hires are worthless. And everyone is not working on a cookie cutter over-bloated rails website. Sorry but this kind of remark simplifying our job always pisses me off.
  - prplhaz4 10y ago
    "can't we just" is top of the list as a trigger for my bullshit detector. In a system of any complexity, changing your data model is an activity that requires due diligence to mitigate any downstream risk.
    - collyw 10y ago
      Me too. When my previous team leader said that, I knew he hadn't bothered to think it through.
  - caseymarquis 10y ago
    At my company, we have one software package it costs on average a quarter million USD to install per enterprise customer. It gets about 100,000 records added per day in some deployments. We test our migrations on those systems and have a dedicated data service which is the only thing which can touch any given customer database. We are paranoid about those systems. We also have throwaway apps like an internal time clock system which monitors when people show up based on their cell MAC. Latter case: Adding a checkbox is easy. Former case: Adding a checkbox is easy but we have to test it first.
    - heartbreak 10y ago
      > which monitors when people show up based on their cell MAC That sounds miserable.
      - caseymarquis 10y ago
        It's voluntary. We're all salary and a portion of our bonus is based on hours worked. When I did the occasional 100 hour week (also voluntary; I work on fun stuff) and forgot to log my hours, I would get credit for it, but there wasn't a direct metric for compensation. We started adding in other employees in multiple departments cause they liked it better than manually tracking.
- krisdol 10y ago
  And that, my friends, is how the first company I worked at ended up with a Contact table of 972 columns.
- arenaninja 10y ago
  If you're working on a database without any data in it, sure. When your tables have millions of records for enterprise customers, it's significantly more involved than you describe
- sontek 10y ago
  This is definitely a common use case and very valid for smaller applications. If I were you though I would avoid applying your experience on smaller scale applications as a way to say that everyone who can't do that are using bad frameworks. Once your application reaches a certain scale there is a huge chance that generated migration could lock a table for minutes to hours which isn't acceptable. We allow developers to run generated migrations in dev/testing environments but when its time to go to staging we evaluate the changes made and check query plans and figure out what type of locking is going to happen and how long it would take it prod. There is very few times the migrations Django or Rails generate are acceptable at our scale in production.
  - caseymarquis 10y ago
    I think you're correct. I was out of line by being too general. For our large scale applications we back up the database and have required down time from our customers while doing a major migration. Everything isn't always simple. But adding a check box in 90% of cases usually is.
    - sontek 10y ago
      Adding a check box in a relational database most likely involves running ALTER TABLE to introduce a new column which in most relational databases locks the table. Now lets say you are doing 15,000 requests per second on that table.... is preventing those from executing acceptable in your system? Its not in mine which is why we don't run ORM generated migrations.
      - caseymarquis 10y ago
        I conceed. For some databases, any adjustment is clearly a major decision with potential consequences. My comment was needlessly inflammatory.
- nameless912 10y ago
  > Push to master. Update production. You monster. You fucking monster. The reality is that ORMs are a huge headache and a chunk of dependency and magic that make some people uncomfortable. Even though I make more mistakes writing the glue code between SQL and my backend than I would with the ORM, I know how every bit of that code works, and I've reduced significantly the magic I have to deal with in order for my code to work (basically, just the database driver since I own everything else). ORMs are a huge surface to secure, tune, and understand, and I think that it's unfair to tell someone their app sucks just because they refuse to use one.
  - caseymarquis 10y ago
    I didn't say his code was bad. I meant whatever they're using for libraries must be a pain to work with. I was overly general, should have used different language, and what I said was flat out wrong for some environments.
    - nameless912 10y ago
      I'm gald you acknowledge that! But seriously. Pushing to master, AND updating production...where are your unit tests!?!?
  - caseymarquis 10y ago
    I didn't say his code was bad. I meant whatever they're using for libraries must be a pain to work with. I was overly general, should have used different language, and what I said was flat out wrong for some environments.
mattm 10y ago
This reminds of I conversation I had with a mobile developer. He came up with a prototype to show to a client. The prototype was just interactive screenshots with nothing going on in the backend. After showing it to the client, the client was excited that the app was pretty much done. The developer explained that this was just a prototype and all the coding still needed to be done. The client couldn't understand and kept saying that it was basically done.

leecarraher 10y ago

i often get the, can we make this a websocket instead of an api call. that way it can just get updated instead of you having to run a query... 1. not neccessarily faster (push vs pull depends entirely on the data creation consumption model) 2. the push scenario is not how most database access patterns work. Instead it's likely just polling the db on the backend instead of the front end. So same db load. and now lots of open connections to simultaneously maintain and garbage collect.