The blog ofJonathan Pepin

2019 tech list

2019-01-20

For the sake of continuous learning and self improvement, I like to fix learning objectives for myself.

I also like to try to learn new technologies, which I allows to discover new ways of thinking. This year is no different, so here's the list of things I'll try to work with!

Typescript

I'm putting this one first because as a full stack engineer, you can't get around Javascript, be it on the frontend or on the backend.

There is not questions about how useful a type system is, and now, with Babel supporting Typescript, there are no reason not to integrate it new and existing projects.

Until now, it seemed too unstable and there was a pretty intense battle between Flow and Typescript, and the possible gains from a so-so type system didn't seem to justify the risk of picking the looser long term (I worked with Flow at Uber a few years ago, and it was definitely still on the too early stages).

Now, it is obvious that Typescript is winning the battle (even teams at Facebook are adopting it, such as Jest - latest team migrating the codebase from Flow), so it makes me a bit more confident to invest into having a whole codebase into it.

Vue.js

While we are in the Javascript ecosystem, I want to mention Vue.js. I've played around with Vue.js already, and although I don't have experience building scalable apps with it (React would still be my go to framework for that) I think it's perfect for smaller or per-page apps.

I've developped my fair share of Single Page Apps, and although the idea sounds always great and simple at first, we often fail to get a posivitive value from it, when weighting in all the complexities coming with it.

The need for server-side rendering if you want any type of SEO, double data management and caching between server and client, dual logging system, etc. For those reasons, unless there is a big, obvious reason for a SPA (and I do believe there are!), I'm often pushing for a more regular MVC architecture with most pages simply rendered server-side (and that doesn't mean less interactive UX).

One architecture this implies is what I call "micro apps", where each page is rendered server side, and a mini JS app is injected for each page. This allows both to have the best of server software while having the snappy, interactive UX of browser apps.

And in this type of architecture, the ease of building mini apps with Vue.js seems perfect.

Elixir and Phoenix

Rails is usually my de facto web framework. It's development speed is stellar, has all the features you need for any web apps and will scale enough to support most apps.

Elixir is a dynamic, functional language designed for building scalable and maintainable applications. It leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development.

Phoenix is a web framework using Elixir, which was originally built to solve problems that Rails was not able to solve in a great way.

First, a lot of cases require better scalability or concurrency than Rails or other web frameworks can offer (for example building a chat application in Phoenix is a breeze).

I also try to stay away from SPAs (and complexities that come with), except for cases where it's very necessary (hint: it's usually not).

Second, if not for that, I think making efforts to work more with a Functional language will help me design better software in other languages such as ruby and javascript.

Elastic Search and the rest of the ELK stack

Logging, metrics and monitoring is always a struggle. Between network and server metrics, web and app logs, and marketing/user behavior analytics, there are still no good, one-stop-shop solution, except for a few SaaS offering, that will cost you a limb every month.

Having all your data in one place and being able to query and analyze it is crucial if you want to understand not only how your software is working, but also how your business is doing. I'm not even talking about the ability to run A/B testing experiments.

Being able to easily and quickly setup an ELK stack for every new app you release is a must, and I want to make this not only a must have item on any development checklist, I want it to be quick and easy. Maybe even automated.