TL/DR: The hot new JavaScript runtime by Ryan Dahl is sleek, powerful, easy to use and best of all, stable in production. The smaller ecosystem compared to Node.js limits your use cases, so it really depends on what you want to use it for. This is not all bad news though, a smaller ecosystem can also mean your project does not get bloated with dependencies. Unlike Node.js, Deno is actually TypeScript native without transpilation, making it simpler to track down server errors. It also a mixed usage model so you can transition your codebase from JS to TS at your own pace. Teams thinking of making the switch over to Golang might want to consider it before going ahead, as it provides a lot of overlap in terms of use cases.

Hiya, my name is Steven de Salas. I’ve been the Founding Engineer and CTO for a Series-A startup in Madrid for the last couple of years. We’ve been running Deno in production for a little under a year.

We are mostly a JavaScript shop running Node.js services and I wanted to comment on my experience setting up a Deno API service and running it. You’re probably busy so I’ll try be as brief as possible. Feel free to write a comment if you want some further clarification.

WHAT IS DENO.JS:

‘Deno’ (‘No-de’ flipped over) is a new JavaScript runtime announced in 2018 by the Node.js creator Ryan Dahl after commiserating his mistakes in a now-famous presentation.

Its basically a re-write of the Node.js JavaScript engine (famous for bringing server-side JavaScript to the masses) and its been getting a fair bit of traction lately. You can read more about it in Wikipedia.

WHAT WE USED DENO FOR:

We used Deno for API integration mainly. Our startup distills information and interacts with many parking providers and most have some sort of JSON API we can talk to, other times we rely on information provided by their website. Its all HTTP in any case. Easily solved with fetch() calls under the hood.

Our stack is essentially: Deno on dockerised Debian, with Oak for Web/API framework and SuperOak for testing. With various libraries added as needed. All running as load-balanced containers hosted in AWS.

❤️ WHAT WE LOVED:

• Native TypeScript. No need to fiddle with ts-node, babel, esbuild or any of the other ways to fit a (TS) square peg into a (Node.js) round hole. TypeScript is supported by Deno natively. There is no setup, config or instructions needed. It just works. The lack of transpilation also means that by default, any errors thrown by the server will point to a line in your source code, not the intermediate transpiled garbage. We used TS for all our libraries and core utility scripts, and JS for the routes. Interoperability is pretty seamless, just change the file extension to .ts and you are good to go.

👍 WHAT ELSE WAS GREAT:

• Stable in production. Never had a hitch with the process. The loads were not huge but it was a critical part of our infrastructure and it ran smoothly all along to the point you forget its even there doing its job.
• Simple to package. Due to its single executable and easily accessible Docker Images, Deno is a breeze to package for production. Even when the docker images were not published, a simple Dockerfile based ondebian:slim with installation script will run your code without a problem.

👎 THINGS THAT WERE ANNOYING OR MISSING:

• Less mature ecosystem. Lets face it, Node.js has NPM so whatever problem your are facing your are usually one npm install away from solving it. This can be annoying with Deno, but it does force you to be minimal about dependencies… a little too much npm install can also ruin your project. For example, if you want to create automated tests for your API, there are 20 different ways you can go about it in Node.js. In Deno you have less choice or you have to build your own. We ended up going with superoak.

🤘 WHAT WAS A BIT HYPED:

• Security model. Deno.js is touted as having a superior security model to Node.js, where permissions are explicitly declared at run-time and enforced by the executable. While this sounds great in theory, the practice of running a real-world use-case such as an API service is that as the project expands and your needs change, you will just keep adding permissions to the main executable in your startup-script. This means that the needs of a single execution pathway (ie GET /document/{documentId}) will also apply to EVERY OTHER execution pathway, so little is gained overall, particularly as projects expand and become more complex. There are ways around this, but honestly, I think it would have been more useful for run-time permissions to be applied to each file on a case-by-case basis.

🤔 PROBLEMS:

• Complex dependencies. The only significant problem we faced was when trying to upgrade our service to include the Chromium's Puppeteer runtime in our deployment. I think this problem would have occurred with Node.js as well. Running a fully-fledged browser as a background process has too many platform-specific requirements in terms of libraries and settings to get right, as well as a forked process running in the background. Components like these tend to make solutions a bit more delicate. We could have got it running given enough time but it was not worth the effort as there were other ways to accomplish what we were after without a headless browser.

WHO WOULD WANT TO USE IT?

Lets face it. A project like this only gains traction because people want to use it. I’ve noticed that Golang has taken a lot of steam out of Node.js for the middle-tier lately.

And why? To me it seems like the main reasons overlap a fair bit with the use-cases for Deno.js.

• Bloatware: Projects written in Node.js suffer from a plethora of unsecured dependencies. Just try npm audita project older than 6 months. This has become worse lately, and its not that Golang or Deno do not suffer from security issues too, just they have far less dependencies to worry about.
• Standardized way of doing certain things: Golang has opinionated linting, testing, and dependency management. Same as Deno.
• Type safety. Golang provides strong types but the syntactic overhead is also fairly light. TypeScript in Deno is not exactly ‘type safe’ but it does overlap a bit in terms of requirements.
• Barrier to entry: Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer.

The only place Deno can’t compete is in raw performance. Deno can compile executables using deno compile however it is still 30% slower than Golang for common use cases.

In my opinion Deno should interest senior developers working in projects that are tired of the Node.js ecosystem, but want to use a similar runtime instead of moving their codebase a different language.

If you are after something minimal, and don’t mind coding your way around certain problems it really provides an excellent platform. I would start with simple use-cases (like we did) and then move on to more complex ones on a case-by-case basis.

About the Author

Steven de Salas is a Founding Engineer/CTO at LetMePark, a Series-A startup based in Madrid. His superpower is coding platforms from scratch with Node.js, <any database> and <any frontend framework>, but he has many other talents like playing board games and explaining homework to his 8-year twins.

Like the article?

Please press the👏 right below you. It helps more people see it.

Aggregation Pipelines are a powerful tool to process millions of records quickly and efficiently. If you have used other database systems before, you may be familiar with Materialised Views (Postgres/Oracle) or Indexed Views (SQL Server).

These are all awesome solutions to one specific problem:

How do I combine vast amounts of information into a single dashboard in a way that requires minimum effort to load?

You see people like to consume information in the form of summary tables and charts, but getting this information ready for them often requires trawling through thousands or millions of records. This is a slow and time-consuming process which should never be executed in real-time every time a user requests the information (they’ll be waiting a long time, and you’ll be doing a lot of processing unnecessarily).

The ideal approach here is two pronged:

1. Have a way of building the aggregate information INSIDE your database, so that your millions of records do not have to be moved around to get the result.
2. Store the result into disk, so it is essentially written once and read many times easily.

While you can define your aggregation pipelines in any language (Node.js, Python, Java, etc..) once they are sent to MongoDb they get executed using C++ inside the MongoDb context, so your thousands/millions of records are processed in an optimized manner and do not need to go anywhere.

You then get a result which may be a few hundred rows long, but contains data put together from thousands or millions of records. This result can then be stored to disk using the $out or $merge aggregation stages, depending on whether you want to replace the resulting collection or add to it.

How to put together your first aggregation pipeline

If you are going to put together an aggregation pipeline for the first time I recommend using MongoDb Compass, which comes with a UI for building pipelines that makes it easy to get familiar with the language for creating aggregation steps.

Once you are done your can export the result to your language of choice.

Use the $out/$merge aggregation and schedule your execution.

Done building your pipeline? No worries, when you are happy with the result don’t forget to add either the $out or $merge aggregation step at the end, this will essentially save your results to disk as the last step of the aggregation.

$out: Replaces the target collection with the results of the pipeline
$merge: Adds to or partially modifies your target collection.

You can then schedule execution through a variety of ways:

• Timed scheduling: Use your favorite scheduler to run your pipeline every few minutes. (I like cron, or cronicle for a great Node.js equivalent with a web UI, but any scheduler will do.)
• Database triggers: You can also run your aggregation pipeline when there is a change to any of your desired collection/s (might be more than one if your data is put together from several collections). I recommend using Atlas Triggers for this (if your database is using MongoDb Atlas). Here is a good write-up.

Why not use another solution?

Aggregation pipelines are the right tool to use if you are already committed to MongoDb.

Obviously it doesn't make a lot of sense to use them if your data is stored in a different backend database. Depending on your database there is probably a more suitable tool for the same niche:

Postgres SQL: Use Materialized Views
MySQL: No equivalent. But can be cooked-up manually with a stored proc.
Couchbase: Use Couchbase Views
DynamoDb: Use Global Secondary Indexes
MSSQL: Use Indexed Views
ORACLE: Use Materialised Views

What is a Founding Engineer?

This is a series of articles on Founding Engineer know-how. But they are useful for all kinds of engineers out there.

A Founding Engineer is a special kind of CTO for startups. Early in a startup (seed or pre-seed), you need a developer who can ship product and then build business around it. CTOs of bigger companies actually don’t spend any time coding. They work on strategy, partnerships, hiring and other higher leverage activities. But that won’t work for a startup.

A founding engineer will turn over a product quickly (ie, get s*** done) and iterate it until your have a working solution for a startup, as nothing is more important than choosing the right market and getting a solution out to that market so that customers can give you feedback (with their dollars). They can build a solution, store the code in Github/Gitlab, setup a database, CI/CD pipelines, cloud hosting, container workloads, email, DNS, SSL, reverse proxying, automated testing, code branching and collaboration guidelines.

In addition to all of that, the founding engineer must communicate with non technical folks, both within the organization (including the CEO) and outside of the company. They need to be able to grow a team from a single person and be willing and able to drive decisions, especially around technical issues, when to hire, which technology stack to use, when to use lowcode/nocode, and when to accrue technical debt and when to pay it back.

About the Author

Steven de Salas is a Founding Engineer/CTO at LetMePark, a Series-A startup based in Madrid. His superpower is building API-based platforms from scratch with Node.js, MongoDb and Vue.js, but he has many other talents like playing board games and explaining homework to his 8-year twins.

Like the article?

Please press the👏 right below you. It helps more people see it.

5 tips for new developers

The last few months I have been teaching an intensive full-stack programming course at Wild Code School in Madrid, and being around people who want to embark on the journey of becoming new developers has made me realise that there is room for advice from an old timer like me🦖.

This article was originally published in the website of Wild Code School and the Madrid blog. This is the re-edited version that is (hopefully) a bit easier to read.

What is your background as a developer?

When I was 8 years old I got a tape-deck ZX Spectrum for Christmas. It came with a whooping 128Kb of RAM and a manual on how to program your own games using BASIC.

I was hooked. Programming computer games was WAY more fun that playing them. Fast-forward 10 years later when the Internet got started and I was keen to build myself a website and help other people with theirs. Before I knew I had too many websites to build and not enough time.

These days I build web and mobile applications, the technologies have changed but there is still plenty of demand. I feel extremely lucky that I get to create interfaces and automations that bring some improvement to people’s lives, and that I get paid for it. In a way its like I’m still making games.

Could you give us 5 tips for people who are planning to become developers?

Sure can, they may not be exactly what you expect, and I bet every developer will tell you something different, but this is the advice I can give.

TIP 1: Get comfortable with feeling useless

Every time i’ve felt confused and useless and ready to give up has been during a period of intense growth. If you want a long and fruitful career as a developer you are going to have to recycle yourself over and over.

I think we usually tell ourselves that learning is an intellectual journey, but from my experience its more of an emotional journey, in other words, a case of letting new knowledge sink in while managing a powerful range of emotions.

You have probably already experienced the feeling of utter uselessness that comes when trying to learn something new, and not doing a particularly good job of it. Well, this feeling is your new best friend, try and welcome it, as it comes when you are growing… Life will be easier if you do. Learn to identify it early and become detached from it, learn to be kind to yourself, and to welcome the knowledge that comes with it.

Just because you feel useless, doesn’t mean that you are useless.

And remember that when you start feeling like you know everything, you are no longer learning and you are getting left behind. Do yourself a favor and keep putting yourself out of your comfort zone so you can keep growing.

TIP 2: Sell your brand

It is scary putting yourself out there, building your network. Specially when there is so much you still don’t know about.

But the reality is that technologies change so fast that many other developers are in a similar situation, they know some things yes, but those are probably outdated, and they will likely have to learn most of their next job anyway. Establishing yourself as a brand will give you choices later. Think of it as an investment. It will mean the difference between finding a job you enjoy and being forced into the least bad of your options.

When you get past the initial shyness, public attention is not so bad. And it saves wasted time on endless job applications which will end up in a black hole anyway. The idea is make it easy for people to find you, so work on every opportunity to make this happen. Try writing articles on LinkedIn, shaking hands with people at meetups, build your portfolio site, share something you’ve read (like this article), talk to people about a project you are working on, make some cool videos or get in touch with recruiting professionals.

Do NOT sell yourself falsely, but put yourself out there anyway. There will be plenty of people that need your skills as they are, even if they are not fully developed, so long as you are open to learning the techology stack specific to that client.

TIP 3: Aim for jobs that expand your knowledge.

Many times I have faced a choice between earning more money or gaining the skills that will push my career in the right direction. I have to say that every time I picked a job for the skills rather than the money, I have been happier in the long run.

I think this is particularly relevant for developers that are getting started with picking their first jobs. Do yourself a favor and point your carreer in the right direction, even if it comes at a cost in the short term.

TIP 4: Build projects you love.

I can’t stress the usefulness of programming something because you love what you are doing.

Try and find time to do this. Life is busy I know, i have have 2 kids. And yet every time I have managed to put time aside to write code for fun I have found some learning that has helped me later in.

This is another way to invest in yourself. Some people are lucky enough to get paid to build something they love. If you can find yourself in this position then great. If not, then there are plenty of opportunities to build cool things too, just seek them out.

TIP 5: Learn to fail.

Lets face it. You are going to break things.

This is particularly true for junior developers.. You can stay away from risk and spend your time adding little value and just getting by, or be useful and risk having sh#t hit the fan.

Obviously tread with care wherever you go. But life is short, and as they say.. `if you want to make an omelette… you have to break some eggs`.

So keep the bigger picture in mind, and when bad things happen (and they will) learn how to avoid blaming yourself and others, and to focus your energy on picking up the pieces (with the help of your seniors). If you do this well, the damage will usually be minimal, yet the lesson will be invaluable.

Each time your break something, remember 3 things:

1. DON’T make it worse in a panic.
2. Be open, and put your effort on recovery, not on finding blame.
3. Take steps to avoid it happening again. This doesn’t mean firing people, it means automating the process to avoid what just happened.

If you take this approach you will generally gain the respect of your peers and managers, who have probably gone through the same right of passage at some point.

What other advice could be useful?

Be yourself.

Honestly, work (and life) is hard for everyone. If you behave as yourself in as many interactions as possible (yes, even that job interview), and you make as many honest choices along the way as you can, you will find a measure of peace in all the chaos and pain that life has to offer.

Whatever path you choose, you can’t take the suffering away, but you can add the satisfaction that every step of the way you did what was most true to yourself as a person.

So go forth ✌️, and be fruitful 🍇 🍓 🍍🍒 …

.. and remember to clap 👏 if you enjoyed this. So more people can see it.

My parents bought me a Sinclair ZX Spectrum when I was 8 years old. It came with a manual for how to write your own games using BASIC.

I was there early. Looking back I remember long spells in front of the computer in absolute focus. I wrote tick-tac-toe, arkanoid, monopoly, space invaders, even a stock market simulator.

I kept coming back because writing code provided a sense of achievement and a state of mind that I rarely experienced in any other setting. I was absolutely focused, incredibly productive and I enjoyed it.

But it doesn’t leave room for much more.

As a kid sometimes my parents would talk to me and I wouldn’t respond until later when they’d already left the room. I wasn’t being rude intentionally, I was just so immersed in what I was doing that I forgot to respond, or rather, the response got queued up behind whatever else I was doing.

If you are reading this you probably know what I’m talking about. I wasn’t aware that it had a name until I heard it being described as Flow (or ‘the zone’) well into my career.. I just knew it as what happened to me when I got deep into a project.

Social interaction. The negative side of Flow.

For a long time I’ve been aware (and wary) of the relationship between Flow state and my capacity for social interaction.

Basically, the more I code the worse I am at talking to people. The more I talk to people the worse I am at coding.

Its like I’m walking a tightrope and on one side is maximising my productivity, and on the other my capacity to interact with others and maintain a high degree of verbal fluency.

A combination of both is necessary if you want to succeed, after all its pretty useless if you are super-productive doing something that is not wanted or necessary. Plus you don’t want to neglect relationships with your co-workers.

But you can also take it too far the other way, say, if you land a role that involves a large amount of mentoring or managing stakeholders. You can lose the ability to perform your core skill writing code, to the point of being unable to provide useful advise and sending people off-track.

I’ve had both happen to me, and everything in between. Now I try to settle for happy medium so I can be useful doing what I love.

How do you enter Flow willingly?

There are a few ingredients needed to enter flow state.

You need an interesting problem — one that is within or just beyond your capacity— and a block of time to dedicate to it exclusively. I also like to listen to trance music. Psy Trance, Progressive, Epic Trance, anything with a steady beat.

I find its easier to enter flow state that way. Doesn’t always work but it tends to do so more often that not.

How do you exit Flow gracefully?

I can’t say I’m the most graceful at it, depending on how deeply concentrated I am I tend to jump, mumble, ask for clarification multiple times until I can shift my focus etc.

What I have learnt is that regardless of how far you need to resurface, you must be prepared to drop it all for the person that is standing in front of you. It is the willingness to detach yourself that helps make the exit as graceful as it can be.

Worth reading?

Please press the👏 right below you. It helps more people see it.

So if everyone says Immutability is good, that means mutating objects is bad, right?

I wrote this originally as a answer to a stack overflow question posted by someone who was as baffled by this JavaScript programming trend as I was.

Here is my answer to this topic, it is contrarian and may also be contentious, but bear in mind its not the only answer, its just my own point of view.

Why is immutability so important(or needed) in javascript?

Well, I’m glad you asked!

Some time ago a very talented guy called Dan Abramov wrote a javascript state management library called Redux which uses pure functions and immutability. He also made some really cool videos that made the idea really easy to understand (and sell).

The timing was perfect. The novelty of Angular was fading, and JavaScript world was ready to fixate on the latest thing that had the right degree of cool, and this library was not only innovative but slotted in perfectly with React which was being peddled by another Silicon Valley powerhouse.

Sad as it may be, fashions rule in the world of JavaScript. Now Abramov is being hailed as a demigod and all us mere mortals have to subject ourselves to the Dao of Immutability… Wether it makes sense or not.

What is wrong in mutating objects?

Nothing!

In fact programmers have been mutating objects for er… as long as there has been objects to mutate. 50+ years of application development in other words.

And why complicate things? When you have object cat and it dies, do you really need a second cat to track the change? Most people would just say cat.isDead = true and be done with it.

Doesn’t (mutating objects) make things simple?

YES! .. Of course it does!

Specially in JavaScript, which in practice is most useful used for rendering a view of some state that is maintained elsewhere (like in a database).

What if I have a new News object that has to be updated? … How do I achieve in this case? Delete the store & recreate it? Isn’t adding an object to the array a less expensive operation?

Well, you can go the traditional approach and update the News object, so your in-memory representation of that object changes (and the view displayed to the user, or so one would hope)...

Or alternatively…

You can try the sexy FP/Immutability approach and add your changes to the News object to an array tracking every historical change so you can then iterate through the array and figure out what the correct state representation should be (phew!).

I am trying to learn what’s right here. Please do enlighten me :)

Fashions come and go buddy. There are many ways to skin a cat.

I am sorry that you have to bear the confusion of a constantly changing set of programming paradigms. But hey, WELCOME TO THE CLUB!!

Now a couple of important points to remember with regards to Immutability, and you’ll get these thrown at you with the feverish intensity that only naivety can muster.

1) Immutability is awesome for avoiding race conditions in multi-threaded environments.

Multi-threaded environments (like C++, Java and C#) are guilty of the practice of locking objects when more than one thread wants to change them. This is bad for performance, but better than the alternative of data corruption. And yet not as good as making everything immutable (Lord praise Haskell!).

BUT ALAS! In JavaScript you always operate on a single thread. Even web workers (each runs inside a separate context). So since you can’t have a thread related race condition inside your execution context (all those lovely global variables and closures), the main point in favour of Immutability goes out the window.

(Having said that, there is an advantage to using pure functions in web workers, which is that you’ll have no expectations about fiddling with objects on the main thread.)

2) Immutability can (somehow) avoid race conditions in the state of your app.

And here is the real crux of the matter, most (React) developers will tell you that Immutability and FP can somehow work this magic that allows the state of your application to become predictable.

Of course this doesn’t mean that you can avoid race conditions in the database, to pull that one off you’d have to coordinate all users in all browsers, and for that you’d need a back-end push technology like WebSockets (more on this below) that will broadcast changes to everyone running the app.

Nor does it mean that there is some inherent problem in JavaScript where your application state needs immutability in order to become predictable, any developer that has been coding front-end applications before React would tell you this.

This rather confusing claim simply means that if you use React your application is prone to race conditions, but that immutability allows you to take that pain away. Why? Because React is special.. its been designed first and foremost as a highly optimised rendering library with state management subverted to that aim, and thus component state is managed via an asynchronous chain of events (aka “one-way data binding”) that optimize rendering but you have no control over and rely on you remembering not to mutate state directly…

Given this context, its easy to see how the need for immutability has little to do with JavaScript and a lot to do with React: if have a bunch of inter-dependent changes in your spanking new application and no easy way to figure out what your state is currently at, you are going to get confused, and thus it makes perfect sense to use immutability to track every historical change.

3) Race conditions are categorically bad.

Well, they might be if you are using React. But they are rare if you pick up a different framework.

Besides, you normally have far bigger problems to deal with… Problems like dependency hell. Like a bloated code-base. Like your CSS not getting loaded. Like a slow build process or being stuck to a monolithic back-end that makes iterating almost impossible. Like inexperienced devs not understanding whats going on and making a mess of things.

You know. Reality. But hey, who cares about that?

4) Immutability makes use of Reference Types to reduce the performance impact of tracking every state change.

Because seriously, if you are going to copy stuff every time your state changes, you better make sure you are smart about it.

5) Immutability allows you to UNDO stuff.

Because er.. this is the number one feature your project manager is going to ask for, right?

6) Immutable state has lots of cool potential in combination with WebSockets

Last but not least, the accumulation of state deltas makes a pretty compelling case in combination with WebSockets, which allows for an easy consumption of state as a flow of immutable events…

Once the penny drops on this concept (state being a flow of events — rather than a crude set of records representing the latest view), the immutable world becomes a magical place to inhabit. A land of event-sourced wonder and possibility that transcends time itself. And when done right this can definitely make real-time apps easier to accomplish, you just broadcast the flow of events to everyone interested so they can build their own representation of the present and write back their own changes into the communal flow.

But at some point you wake up and realise that all that wonder and magic do not come for free. Unlike your eager colleagues, your stakeholders (yea, the people who pay you) care little about philosophy or fashion and a lot about the money they pay to build a product they can sell. And the bottom line is that its harder to code for immutability and easier to break it, plus there is little point having an immutable front-end if you don’t have a back-end to support it. When (and if!) you finally convince your stakeholders that you should publish and consume events via a push techology like WebSockets, you find out what a pain it is to scale in production.

Now for some advice, should you choose to accept it.

A choice to write JavaScript using FP/Immutability is also a choice to make your application code-base larger, more complex and harder to manage. I would strongly argue for limiting this approach to your Redux reducers, unless you know what you are doing… And IF you are going to go ahead and use immutability regardless, then apply immutable state to your whole application stack, and not just the client-side, as you’re missing the real value of it otherwise.

Now, if you are fortunate enough to be able to make choices in your work, then try and use your wisdom (or not) and do what’s right by the person who is paying you. You can base this on your experience, on your gut, or whats going on around you (admittedly if everyone is using React/Redux then there a valid argument that it will be easier to find a resource to continue your work).. Alternatively, you can try either Resume Driven Development or Hype Driven Development approaches. They might be more your sort of thing.

In short, the thing to be said for immutability is that it will make you fashionable with your peers, at least until the next craze comes around, by which point you’ll be glad to move on.

And the reply!

Hello Steven, Yes. I had all these doubts when I considered immutable.js and redux. But, your answer is amazing! It adds lot of value and thanks for addressing every single point that I had doubts on. It’s so much more clear/better now even after working for months on immutable objects. — bozzmob

I’ve now added this as an article in my blog => Immutability in JavaScript: A Contrarian View. Feel free to reply in there if you have strong feelings you’d like to get off your chest too ;).

Like what you are reading?

Click on the 👏 below, it helps more people see it.