When I first started getting into the world of software development, it felt like I was diving into the deep end of a pool just to get something out there.
First, I had to learn what the difference was between frontend and backend, and why that distinction exists.
Then I had to learn how to create an API so that my frontend could communicate with my backend (you wouldn't believe how long it took me to finally realize what an "API" was).
And once I understood that, I thought I was doing fine for a while...
...until I tried to put my app on the cloud.
When coming to the deployment step, I was suddenly overwhelmed by the number of things that go into setting up my server: Containerization, Kubernetes, Load balancers, CDNs, etc.
Once I did that, I had to set up a CI/CD pipeline so my code could get to the server safely.
I had thought the coding was the hard part, but it turns out I spent more time figuring out how to set up my server than I did writing my application code.
Wouldn't it be nice if we didn't have to worry about deployments and all the complexity of server infrastructure? And we could just focus on our code?
That's what Darklang is all about.
Dark is a new holistic programming language, editor, and infrastructure that allows you to be more productive by removing all the complexity I just described.
It is currently in private beta, so you won't be able to access it right away.
It's really unlike anything we've seen before, so be prepared to let go of everything you are used to in software development.
The most difficult thing to wrap your head around is that Dark is not just a programming language. It is a programming language, editor, and infrastructure all very tightly integrated together.
I think the best way to explain it is with an example. When I created High/Low, I wrote my server in Python using Flask. Let's take a quick look at my backend code for just the authentication portion (I'm linking to a Gist because it's almost 600 lines...).
Now, as a disclaimer I want to mention a few things:
- I'm not going to pretend like this is the best code ever. There's a lot of repeated code, and maybe some not-so-best practices...
- Also, this code is doing a lot of things that I won't be demonstrating with Dark - i.e. OAuth authentication, forgot password flow, refresh tokens, etc.
- This doesn't cover the API endpoint definitions
So I wrote all that code, and then had to go and set up the server on Google Cloud to host all of this nonsense.
With those things in mind, let's see what a (very) simple authentication system might look like to set up on Dark.
Dark uses a few basic constructs to define your infrastructure: HTTP Handlers, Workers, Cron jobs, and Datastores. You can also create "REPL"s, but from my understanding these are more for ease of development than for production purposes.
If you look in the image below, I have created two HTTP handlers (one for signing in and one for signing up), and a Datastore to store my users using a very simple schema:
Literally, that is all I did and I have a server up and running. No configuration, no containers or load balancers to worry about.
Let's take a closer look at these three blocks. First, let's examine the datastore:
Each user will have a name, a username, and a password. The Password type is special, and has protections to keep it from being leaked. This is important because of a concept called "Live Values" that I'll talk about later.
Next, let's take a look at sign_up:
You'll notice that this looks like fairly normal code. The big difference is that the Dark programming language is based on expressions, which have fields that need to be filled. By working this way, with it's special editor, it is impossible to make a syntax error. At every step, you have a syntactically correct block of code, though it can be incomplete if you haven't filled all the fields.
All we're doing here is getting the username, name, and password from the request, and setting it into the database.
Then we sign and encode a JWT to return to the user (getPrivateKey is a function I made that returns an RSA key).
The sign in handler is very similar:
Here, we get the username and password from the request, then look up the user with that username, and finally check the password to see if it matches.
If it does, we sign and encode a JWT just like in sign up. If it doesn't, we print an error message.
The best part is, I didn't have to go through a deployment process at all. There wasn't even some sort of magic "Deploy" button. In fact, I never even had to "save" my code. I just typed it, and it was immediately available on the server. This is why Dark has been called "deployless".
The last thing I want to talk about is Dark's "Trace-Driven Development". It's difficult to explain without showing, so I'll link to a demo video they made that shows how this works.
Basically, you can make a request to a non-existing endpoint, and it will show up in your "404s" section (see the first image on the left sidebar). From there, you can quickly add an HTTP handler that fits the request.
Then, as you are coding, you'll be able to see values specific to that request show up as you type. This largely eliminates the need for a debugging tool, or the ol' "put print statements everywhere to see what's happening" trick.
For a better explanation of this, check out their docs: darklang.github.io/docs/trace-driven-develo..
Finally, if none of that made any sense, please check out both of the videos on the homepage of their website .