real_ben_michel's comments

Seems to be down in a bunch of places https://istheservicedown.co.uk/status/gmail

Super similar to what I use (http://www.casaspanish.co.uk).

Django has just so much stability, it was an obvious decision for me to go with it. And that's speaking as someone who has mostly worked with NodeJS/React for the past 5 years.

I love the pythonic principle of "There should be one obvious way to do it". This helps me cut down on decision making which is something quite annoying to deal with as sole-tech-founder. Now I get to focus on the business, and technology is just a matter of execution.

Actually, programming is just a small part of the product development process. A huge amount of work is spend on communication, architecting, planning, gathering user requirements, maintenance... Then you need deep knowledge of the technical domain. In that regard, I would say FE and BE differ tremendously. The constraints are different, the people with whom you engage are different, the objectives are different. It won't be very obvious in small companies and young product teams where everyone does a bit of everything. As things scale up and gain maturity, people have to specialise, and it becomes very hard to be the best at both. You have to pick: making great UI components, or storing data optimally. You can be average and do a bit of both, but if you want to be an expert engineer, you'll need to specialise in one (which is what I think d--b was referring to).

Having seen many product teams implement graphQL, concerns were never around performances, and more around speed of development.

A typical product would require integrations with several existing APIs, and potentially some new ones. These would be aggregated (and normalised) into a single schema built on top of GraphQL. Then the team would build different client UIs and iterate on them.

By having a single queryable schema, it's very easy to build and rebuild interfaces as needed. Tools like Apollo and React are particularly well suited for this, as you can directly inject data into components. The team can also reason on the whole domain, rather than a collection of data sources (easier for trying out new things).

Of course, it would lead to performance issues, but why would you optimise something without validating it first with the user? Queries might be inefficient, but with just a bit of caching you can ensure acceptable user experience.