This is the entire reason for Node's existence no? Nobody who was in the backend space prior to it's arrival was in anyway excited about JS running in their servers. Node however allowed people with only front end experience to make that transition and start writing backend apps / logic / functions using the same language and now it's an insanely popular project.
Wanting a common backend / frontend language seems like a perfectly reasonable goal especially on smaller teams.
Dart has a LOT of catching up to do when it comes to the overall size of the ecosystem here to be fair because in reality as of right now 90% of the Dart community is just Flutter and nothing else.
However, from a straight up language perspective it has a lot of big advantages over JS when it comes to writing backend code but close to zero momentum / adoption.
It's a space I am currently very interested in personally because I feel like I see a path here that is currently more or less undiscovered. I would say the "secret" I have discovered to making it work thus far is very heavily tied to finding the right abstractions / entry points and caveating it with just like Node and any other backend stack it clearly isn't the right choice for all solutions.
Where I ended up landing was basically:
===Front End===
Flutter for applications and Lit (different project not related to Dart / Flutter but TypeScript is VERY similar and a small team can handle both no problems) for websites. Flutter in particular if you are looking to do anything that isn't JUST web otherwise Lit might be a better choice currently for just web but I expect that calculus to possibly change in 2-3 years as Flutter's web support matures.
===Backend===
Went all in on Google Cloud stack, skipped K8s and instead went with Cloud Run. Only create a gRPC interface in my code but take advantage of the API gateway product to pick up the following benefits:
- Natively integrates with Google's core service infrastructure so my code gets run the exact same way and with the exact same benefits as when I use a native Google API. This gets me all the same security, monitoring, tracing, serving, deployment etc out of the box with zero effort on my behalf.
- Working with gRPC over handrolling JSON interfaces is night and day when it comes to both performance and developer experience. It's just better in every conceivable way. I don't write any manual glue code between my front and backend. Everything is autogenerated and typesafe.
- Just to continue the gRPC story in general for a second, it also addresses one of the bigger limitations of Dart on the server which is that small ecosystem. The majority of things I need to integrate with now are other Google services which is supported both through an official autogenerated library (HTTP / JSON transport) but also I can just use the proto files Google provides to do a native gRPC integration if I wanted to.
It does however also let me think about 3rd party integrations in a different way now. Let's take an example like Stripe. No native Dart library, no gRPC interface etc. One option is to just just HTTP and do it manually but I don't want to maintain that. Another low cost idea I have found for this kind of scenario is that it doesn't feel like a big deal to just break out that functionality into it's own service and take one of their well supported integration options like Node as an example. Take advantage of the fact that the SDK code continues to be maintained by Stripe and I only have to pick whatever calls I want and drop a gRPC interface on top of it that aligns with whatever functionality I want using a well established pattern so I don't have to do too much cowboy coding and I keep a clean separation of concerns in the process (https://martinfowler.com/articles/gateway-pattern.html) in practice I haven't had to do this much but if you have a lot of 3rd party services you are using that would be something to consider.
- Also worth mentioning that making use of Google Cloud's API gateway (https://cloud.google.com/api-gateway) also get's me a free JSON / REST gRPC gateway for web along with a free gRPC-web gRPC gateway which is a necessary feature until WebTransport (https://web.dev/webtransport) makes native gRPC in the browser a viable option.
- Because I am intentionally aligning myself against Google's native service infrastructure (it's pretty similar to the K8s one which is where it comes from but the key difference here is I don't touch any of the complexity myself) I pick up an amazing resource in terms of how to actually write and structure my APIs here https://google.aip.dev/ which gives me a totally coherent set of standards and patterns no matter what I am writing. This keeps my entire backend horizontally scalable and aligned with all the relevant "cloud native" best practices by default.
- Cloud Run and Cloud Native Buildpacks (https://buildpacks.io/) get me a incredibly slick CI/CD pipeline that takes less than an hour to set up. The experience is basically Heroku where I just push code to the dev / non-dev / prod branch and everything just works.
- The images I run are tiny, they are just a single binary compiled to native x86 code and placed inside a blank Docker image thanks to Buildpacks. Google maintains the image best practices for me so I never am touching Dockerfiles for example. Not only is start up time incredibly quickly (meaning I can now safely do scale to zero) but runtime performance is also great because again... it's native x86 code.
- Managed services for everything else such as Firestore or managed Postgres for a DB, managed redis for caching etc..
- The security story is also amazing. Because Dart is a Google project and I am staying pretty strictly in the Google ecosystem I get signed binaries, signed images, a secure build environment, I get SBOMs (https://www.cisa.gov/sbom) in my container image (thanks to Buildpacks) so I know exactly what is running at any given point across time. The Google Build platform and Dart are also both converging on the SLSA standard (https://slsa.dev/) and will allow me to hit level 4 compliance by the end of the year. I rarely need a lot of 3rd party code dependencies (the difference here between Dart and Node in particular is absolutely wild).
- The overall developer experience is also incredible. Dart and Flutter's tooling is genuinely first class. As I mentioned elsewhere a few times in this thread, Google's primary money making venture (Ads) is all Dart and as a result they have put a LOT of effort in at this level to keep things smooth and predictable. For example when new versions of the language roll out I just run a single command `dart fix` (https://dart.dev/tools/dart-fix) and it just upgrades my code for me with no work on my behalf to the latest best practices. There are a whole range of features like this that is just one of them but it helps demonstrate the kind of thing I am talking about.
- Also keeping with the overall security / DX theme the developer onboarding story is also great. I don't have Flutter or Dart SDKs on my machine. I set up a VSCode devcontainer to create reproducible dev environments that just work. That clears up another whole set of potential problems for me if I want to do local development but it also allows me to sit down at ANY computer now and take advantage of Github's Codespaces and without any setup required I have a fully remote secure development environment.
===Wrap Up===
That's what fullstack Dart looks like for me currently as a solo developer. It get's me an incredibly slick setup that rivals most companies out there today. I didn't mention this in the post but I was also very intentional about building sensible escape hatches if I need to escape the GCP ecosystem for some reason. The upgrade path out of there is basically all of this can transfer to plain K8s if that is your thing and you have the resources to support it. I picked open source projects / standards wherever possible despite that initially reading as an incredibly Google focused stack which it also is to be fair.
Also not covered here is the tension I guess between "microserves" and monoliths. I'm doing solo dev work so microservices don't make sense to me and I think are also just a dumb place to start in general. This let's me basically write this super nice combination between the two where I have a single API binary that contains multiple entry points "services in gRPC lingo" (roughly equivalent to "a group of routes in HTTP lingo") that really cleanly abstract out into their own thing as required. So for example let's say you were building a SaaS application the path to go from a single server / deployment running multiple "services" that covered everything from the apps core functionality to billing to admin stuff and to then split them back out into their own independent set of APIs (app-api, billing-api, admin-api) is really pretty trivial (mostly copying and pasting, no big code changes) and because I am using that native GCP service infrastructure the integration setup is tiny and not meaningfully different to say I wanted to bring in any other Google API to my codebase.
But the important part to me here is that it gives me the time and space to find those abstractions as needed and not have to start there. My previous observations around people going from monolith to microservice is that it usually means a total rewrite and it's never feasible until things are seriously on fire and then it becomes a rush job and you end up with even more problems. This keeps the conceptual alignment from the start without needing to take on the risk and the complexity from day 1. It's a path that I think makes sense for everything from start ups to many companies doing serious growth numbers and let's you build consistent tooling / workflows around that.
Honestly, it's worth exploring. Like I said, this is NOT at all a well documented path at the moment but I hope I find the chance to write about this more in the future because what I found so far has been nothing short of amazing.