Hot Take: Dart makes a Great Server Side Language




Dart programming language | Dart


Google promotes Dart as a client-optimized language for fast apps on any platform.  This makes a ton of sense. Bootstrapping a language ecosystem is an enormous task that requires laser like focus on where the language adds the most value. Right now, that is Flutter. 

Sometimes, when a language finds success in one domain it can cross over to another.  One can argue that NodeJS  would never be a thing had Javascript not been adopted in the browser. 

Can Dart cross over to the server? I think it can.  

Recently I created a Cloud Run service to perform smoke tests against another REST service. Golang would be the obvious choice here: Container friendly, small native binaries and a great http library out of the box.  

Now Go is a fine language, and this is a purely subjective thing, but I find Dart much more enjoyable and productive to work with.  There are of course fewer server side libraries, but the ecosystem is growing quickly, and the standard Dart library is really well designed. I've said this before: Dart is the most fun language that I have used in a long time. It behaves like you expect it to, and the tool chain is amazing (hot reload is so sweet...)

To make a long story short, Dart did an admirable job at this task. But what really took me by surprise was the final image size of the container:  Using the "scratch" docker image, and the dart2native compiler (Dart has a VM, but it can also compile to native code), the final container weighs in at 12.9 MB, or 5.2MB compressed (as reported by gcr.io).

12.9 MB! Let that sink in for a bit. Even using Go, I think one would be hard pressed to create a smaller "cloud ready" docker image.  

I'm speculating, but I think the primary reason dart2native does so well here is tree shaking. The compiler aggressively prunes code that it knows can not be reached.  This includes your code, but also any libraries that you depend on (presumably even including the Dart standard library). This results in a very small binary that is mostly the Dart runtime.

If you want to look at Dart on server, here are some suggestions:
  • For a batteries included http server framework (REST, postgres, ORM, etc.), check out https://aqueduct.io/
  • Just need a dead simple http service? shelf and its various plugins is a great option
  • dio is really nice http request wrapper on top of the Dart http library. 

Location: Calgary, AB, Canada

Comments

Post a Comment

Popular posts from this blog

Introducing ds-operator, the ForgeRock Directory Services Operator for Kubernetes

Image
ForgeRock Directory Services 7.0 was a big achievement for the Grenoble Directory team.  It is the only "Kubernetes native" directory where you can add a new replica using kubectl: kubectl scale sts/ds-idrepo --replicas=3 The 7.0 deployment is assembled using standard Kubernetes primitives such as StatefulSets , Persistent Volume Claims, and Services.  This is all built and orchestrated using Skaffold and Kustomize .  An emerging pattern in the Kubernetes world is the use of Custom Resources and Operators .  Broadly speaking, a custom resource is the declaration of the desired system state, and the operator's job is to observe the current state and bring the system into alignment with the declared state: source: https://blog.container-solutions.com/kubernetes-operators-explained The Kubernetes API server (the thing that responds to your kubectl commands) can be extended to handle new custom types.  A custom resource definition (CRD) describes to the API server the syntax
Read more

Automating OpenDJ backups on Kubernetes

Image
Kubernetes   StatefulSets  are designed to run "pet" like services such as databases.   ForgeRock's OpenDJ LDAP server is an excellent fit for StatefulSets as it requires stable network identity and persistent storage. The ForgeOps project contains a Kubernetes Helm chart to deploy DJ to a Kubernetes cluster. Using a StatefulSet, the cluster will auto-provision persistent storage for our pod. We configure OpenDJ to place its backend database on this storage volume. This gives us persistence that survives container restarts, or even restarts of the cluster. As long as we don't delete the underlying persistent volume, our data is safe. Persistent storage is quite reliable, but we typically want additional offline backups. The high level approach to accomplish this is as follows: Configure the OpenDJ container to support scheduled backups to a volume. Configure a Kubernetes volume to store the backups. Create a sidecar container that archives the backups
Read more

Deploying the ForgeRock platform on Kubernetes using Skaffold and Kustomize

Image
If you are following along with the  ForgeOps repository, you will see some significant changes in the way we deploy the ForgeRock IAM platform to Kubernetes.  These changes are aimed at dramatically simplifying the workflow to configure, test and deploy ForgeRock Access Manager, Identity Manager, Directory Services and the Identity Gateway. To understand the motivation for the change, let's recap the current deployment approach: The Kubernetes manifests are maintained in one git repository ( forgeops ), while the product configuration is another ( forgeops-init ). At runtime ,  Kubernetes init containers clone the configuration from git and make it  available to the component using a shared volume. The advantage of this approach is that the docker container for a product can be (relatively) stable. Usually it is the configuration that is changing, not the product binary. This approach seemed like a good idea at the time, but in retrospect it created a lot of c
Read more