4 ms·

Building your backend/s and frontend/s in the same language makes keeping your data model, api inputs/outputs and business validation consistent much simpler an

Building your backend/s and frontend/s in the same language makes keeping your data model, api inputs/outputs and business validation consistent much simpler and easier.

sgarland 3y ago
I have met perhaps a handful of devs who care about a good data model, or even know what one is. Most seem to think that JSON is god’s gift to mankind, and that RDBMS are weird boxes you throw said JSON – along with random scalars for fun – into, and then you can blame the DB for being old and slow when your latency is abysmal.
- hn_throwaway_99 3y ago
  > I have met perhaps a handful of devs who care about a good data model, or even know what one is. Then you have worked with an abnormally large amount of shitty devs.
hn_throwaway_99 3y ago
In addition, especially for smaller teams, there is huge value in teams that can easily go between front-end and back-end code. Before I worked at an "all Typescript" shop, lots of times someone on the front end would need some small additional piece of data or an extra API call from the server team. They almost never did it themselves, and it wasn't so much that they couldn't read/code in Java, it's that the environment setups were so different. It just was rarely worth it to them to spend all the time setting up the backend environment (again, in a language they could understand but weren't "used to" in their day-to-day) to make a couple line change. Worse, some enterprising folks would set it up, but then since they only needed to make backend changes once in a blue moon, the next time they needed to make a change they'd have to spend a ton of time again getting their environment updated. There is huge value to using the same language, and coding environments, across front and back ends.
- freedomben 3y ago
  I used to say the same thing, but after 10 years of using node on the backend I no longer think that's worth much. The amount of code sharing I've experienced has been pretty minimal. You can definitely architect your app around it to make it more useful, but with some rare exceptions, on the backend you are working with the entire dataset/database, and on the frontend you are working on a small subset. I just haven't found the amount of code-sharing to be significant because things are so different. The huge productivity gains of frameworks like Phoenix (Elixir) have in my experience far outweighed the gains from code-sharing. This is all just my personal experience of course, so I'd love to hear from others if this really ends up benefitting them enough to be worth it.
  - hn_throwaway_99 3y ago
    To emphasize, I agree with everything you've said, but I don't really think "code sharing" is the right metric. The important boost from my perspective is that it makes it much easier for front end devs to unblock themselves for relatively small issues, and it also makes it much easier for any dev to debug when they can easily follow the code through the whole stack. E.g. in the past I've seen it take weeks (that is, one or two sprints' worth) to add a teeny bit of data to the front end. Reason being the request had to go to the back end team, then it had to get prioritized and added to the sprint, yada yada everyone's been there. When everything is in the same language I've seen front end devs be much less reticent to just make the change themselves.
    - freedomben 3y ago
      Thanks yeah, ability to unblock yourself on the frontend is definitely a big benefit. Most of the places I've worked are "full stack" so this isn't usually an issue, but it definitely is in some situations. As an aside, I've also kind of turned against "full stack" as largely unrealistic. There are of course exceptions, but most people seem to feel much higher affinity for one side or the other, and as a result often are just so much more effective and efficient when the scope is more limited to their comfort zones.
dventimihasura 3y ago
That may very well be a valid reason why people should build backends in node. But, people don't often listen to reason.

Building your backend/s and frontend/s in the same language makes keeping your data model, api inputs/outputs and business validation consistent much simpler and easier.

sgarland 3y ago

I have met perhaps a handful of devs who care about a good data model, or even know what one is. Most seem to think that JSON is god’s gift to mankind, and that RDBMS are weird boxes you throw said JSON – along with random scalars for fun – into, and then you can blame the DB for being old and slow when your latency is abysmal.

hn_throwaway_99 3y ago
> I have met perhaps a handful of devs who care about a good data model, or even know what one is. Then you have worked with an abnormally large amount of shitty devs.

hn_throwaway_99 3y ago

In addition, especially for smaller teams, there is huge value in teams that can easily go between front-end and back-end code. Before I worked at an "all Typescript" shop, lots of times someone on the front end would need some small additional piece of data or an extra API call from the server team. They almost never did it themselves, and it wasn't so much that they couldn't read/code in Java, it's that the environment setups were so different. It just was rarely worth it to them to spend all the time setting up the backend environment (again, in a language they could understand but weren't "used to" in their day-to-day) to make a couple line change. Worse, some enterprising folks would set it up, but then since they only needed to make backend changes once in a blue moon, the next time they needed to make a change they'd have to spend a ton of time again getting their environment updated. There is huge value to using the same language, and coding environments, across front and back ends.

freedomben 3y ago
I used to say the same thing, but after 10 years of using node on the backend I no longer think that's worth much. The amount of code sharing I've experienced has been pretty minimal. You can definitely architect your app around it to make it more useful, but with some rare exceptions, on the backend you are working with the entire dataset/database, and on the frontend you are working on a small subset. I just haven't found the amount of code-sharing to be significant because things are so different. The huge productivity gains of frameworks like Phoenix (Elixir) have in my experience far outweighed the gains from code-sharing. This is all just my personal experience of course, so I'd love to hear from others if this really ends up benefitting them enough to be worth it.
- hn_throwaway_99 3y ago
  To emphasize, I agree with everything you've said, but I don't really think "code sharing" is the right metric. The important boost from my perspective is that it makes it much easier for front end devs to unblock themselves for relatively small issues, and it also makes it much easier for any dev to debug when they can easily follow the code through the whole stack. E.g. in the past I've seen it take weeks (that is, one or two sprints' worth) to add a teeny bit of data to the front end. Reason being the request had to go to the back end team, then it had to get prioritized and added to the sprint, yada yada everyone's been there. When everything is in the same language I've seen front end devs be much less reticent to just make the change themselves.
  - freedomben 3y ago
    Thanks yeah, ability to unblock yourself on the frontend is definitely a big benefit. Most of the places I've worked are "full stack" so this isn't usually an issue, but it definitely is in some situations. As an aside, I've also kind of turned against "full stack" as largely unrealistic. There are of course exceptions, but most people seem to feel much higher affinity for one side or the other, and as a result often are just so much more effective and efficient when the scope is more limited to their comfort zones.

dventimihasura 3y ago

That may very well be a valid reason why people should build backends in node. But, people don't often listen to reason.