Deploying a Rust app to AWS can be complicated but Flightcontrol makes it easy. A walkthrough of Zero to Production in Rust on AWS.

Deploying Rust on AWS using Flightcontrol


Today marks the day that I work for Open Social for five years, starting September 19th 2016. All advice for people my age tells me I should’ve switched jobs 2-4 times by now. I’d like to use this milestone as a moment to reflect on why I haven’t followed the trend.

I started working at Open Social right after I dropped out of my Electrical Engineering study at the University of Twente. I had tried completing the study for four years but was distracted by board years, committee work and parties. While in theory I had only one year to go I didn’t realistically think I would be able to study full time, especially with my fingers itching to try my hand at a startup idea.

The decision I made at the time was that I could stop with my Electrical Engineering study, hopefully start working for Open Social part-time, try launching my startup idea on the side, and work on a diploma in Business Administration with any time that’s left — as some sort of social safety net (“Here’s a diploma, now please actually look at my CV”) as well as a way to formalise knowledge around how to run an organisation.

I had met Open Social’s founder, Taco, at DrupalCon Prague in 2013 after I had used Drupal to build the website for my sports association. At the time I was too busy with school to start working but he told me the door was always open. A few years later I took him up on the offer.

I vividly remember my first day (this was in the agency days when Open Social was still called GoalGorilla). The project I would be working on had been discussed a little bit before I started but on that first day I was told what my next steps would be. We were working together with a different agency and the project had been ongoing for some time. I would be visiting our partner the next day to get up to speed on the project. Oh, and I would be going alone.

Over the course of 6 months I worked intensely with our partner and the client to finish the project and bring their Drupal based eCommerce site online. Though some readers may be aghast at such a start, I was happy to use the opportunity to prove my worth. Besides, it’s still a fun story to tell at parties.

When I joined the organisation we had only just started working on Open Social as a product. At the time still balancing our existing agency commitments with investments in the product. It’s been an incredible learning experience to see what it takes to transform an agency into a product company. After the initial client project I worked on I joined our marketing team to work on the Open Social marketing website. Later I moved to a dedicated support team before moving into the core team, responsible for maintaing [our open source core](https://www.drupal.org/project/social). From the core team I was involved in [our deployment automation](https://platform.sh/blog/2020/open-social-a-saas-solution-to-deliver-customizable-communities-at-scale/) before spending nearly a year to build [our real-time chat](https://platform.sh/blog/2021/how-to-build-a-real-time-saas-business-with-an-open-source-drupal-core/).

Throughout these years I’ve been accompanied by great colleagues. Some of whom work for Open Social even longer than I do, still going strong. Some who we’ve said goodbye to but still see at drinks or parties. More recently new colleagues who share the enthusiasm for the work we’re doing. One thing that's been a constant throughout the years is room for growth and sharing both lessons learned (through [conference speaking](/talks) and mistakes made, through our minion of the month.

Now, five years later, we still have the habit of throwing people into the deep-end. Though I’d like to think we offer a bit more help in learning how to swim. Luckily the feedback from the people we’ve hired in the last year has been positive in this regard.

As to why I’m not yet looking for the next thing? In the past month I’ve explained to new colleagues, potential hires, and partners alike, over and over again, what our plans are for the future of Open Social. Each time I’m excited about [the challenges that lie ahead](/talks/2020-07-23-on-our-way-to-headless-a-transition-in-progress), the improvements we’ll be able to make and the things that I can still learn.

We’ll be accelerating our push towards a GraphQL API on top of our existing product. This allows our customers to better integrate Open Social into the other tools they use to achieve their mission. It will allow us to further improve our mobile app experience. Finally, my personal focus will be on building a new front-end experience that moves away from Drupal’s page-based world and provides users with a smoother and more interactive experience.

When discussing these plans with developers outside of Open Social I notice that our focus on privacy and customisability, where customers have their own isolated Open Social installation with just the features that they need, provides interesting twists on challenges that others in the headless/React space are facing too. Those coming technical challenges (and the amazing [list of clients](https://www.getopensocial.com/stories/) that Open Social helps reach their goals) are what gets me excited for the years ahead.

_Although I’ve written this post without input from anyone else at Open Social, I have asked them to proofread before publishing. Some of the things that excite us are not quite ready to be shared. Want to help us achieve our ambitious plans? [Open Social is hiring](https://careers.getopensocial.com/)!_



Today marks five years of working at Open Social. Time for a look back on why I'm still around and what's coming next.

Five Years at Open Social


Even people living under a rock will know the main theme of 2020 so there’s little point in repeating it here. However, there are a lot of other things that happened too. Encouraged by the [Blogging for Devs community](https://bloggingfordevs.com/pro/) I’m writing my first ever retrospective. A look back at what I’ve done in the year 2020.

It’s crazy to look back through my calendar and realise there was actually quite a bit of time before working from home started. One of my personal early year highlights was watching the superbowl. I bought an NFL subscription (the introductory price is affordable, the renewal price is outrageous) and watched the whole thing, making nachos at half time. I’ve wanted to watch the entire Super Bowl for quite a few years but always forgot to take the day after off, so being able to watch it this year was really cool. Even though they had [some technical issues](https://twitter.com/search?q=NfL%20from%3AKingdutch&src=typed_query) during the game.

2020 was the year we passed Unix timestamp 1600000000. The last time we saw this many zeroes was in 2017 and the next time will be in 2023. I had become somewhat accustomed to seeing the timestamps starting with “15” when I had to look at database values for debugging.

## The soundtrack of 2020
The work I do as developer is often accompanied by some repetitive music that requires little attention when I’m solving problems or by a podcast when I’m doing something repetitive or waiting for another process (like a Continuous Integration service) to finish.

I’ve already recently looked at [my favourite podcasts for the past year](/blog/2020-12-13-my-favourite-podcasts-of-2020). Most of the music that I listen to arrives to me through Spotify, which provides a useful overview of what I’ve listened to.

<img width="500" class="mx-auto" src="/images/blog/retrospective-2020/spotify-2020-in-review.jpeg" alt="Spotify's #2020Wrapped provides a summary of my year with Spotify. Top artists: Eminem, Russel Brower, Muse, David Arkenstone, Jason Hayes. Top Songs: Dance Monkey, Imagine, Yesterday, Chose Ones, Coming Home. Top Genre: Pop. Minutes listened: 18532." />

At just shy of an hour a day throughout the year, I haven’t used Spotify as much as I thought I had. However, it’s probably still a subscription that I’ll continue in the new year. David Arkenstone and Jason Hayes are both composers for the soundtrack to World of Warcraft which I can listen to for hours on end.

Of interest is that both the artist and song I’ve listened to most were set in the first months of the year. Dance Monkey is a song I’ve had on repeat 6-8 hours a day for 5 days a week for a few weeks of January and February (carried over from 2019). Funny to see how the habits of a few months can shape an entire year.

## Health: Sports
Speaking of habits. This was also the year I’ve said goodbye to my student [Korfball](https://en.wikipedia.org/wiki/Korfball "Korfball (a typical Dutch sport) on Wikipedia") club after being a member for 8 years. This marked the first time in 18 years that I’m not a member of a Korfball club to play the sport.

In 2019 I had already started experimenting with some weight exercises and joined a gym. Although I had seen regular improvements, waking up at 6 AM to be in the gym by 7 AM to exercise before work has never really grown on me.

This year [I was introduced](https://twitter.com/its_txbrown/status/1256193158997848065 "the Tweet that started a new habit") to [Freeletics](https://www.freeletics.com/) which I’ve eagerly adopted as new habit for exercise that I can easily do at home. In that sense i’ve been quite happy working from home since it allows me to do exercise in the middle of the day, right before lunch. A moment when I’ve found I’m fully awake but not yet full from a meal. At the moment of writing I’ve completed 198 workouts since starting in May.

## Health: Food
Another big change this year has occurred after watching the documentary [“The Game Changers” on Netflix](https://www.netflix.com/watch/81157840). After watching the documentary I’ve tried to give a vegan diet a try as a challenge to myself. I’m happy to say that I’ve been eating mostly vegan since the start of September.

I say mostly because with the Christmas holidays you receive some Christmas gifts, snacks and other things that are not necessarily vegan and I find it wasteful to just toss them. My vegan diet can best be described as “I don’t order/buy any food that contains animal but otherwise don’t fuss too much”. I’ve found this to be a comfortable way of getting started. My parents even cooked a vegan nut roast for Christmas dinner, so it may even be rubbing off on them a little bit.

Making sure I eat all the right nutrients and vitamins has been a small puzzle and a bit of guessing work. I haven’t had any blood testing done to check my levels but made sure I ate a varied diet, upped my veggy intake and have started eating [Vitamin Gummies](https://www.yummygums.com/en/ "Yummy Gums - The vitamin gummies") after being told by a vegan colleague that B12 deficiency can be dangerous and takes a while to show itself.

i’ve bought a bunch of cookbooks for some inspiration and subscribed to [The Vegan Plant Club Newsletter](https://theplantbasedclub.substack.com/) for plenty of recipes on things I can cook. I’ve also noticed that in Dutch supermarkets the amount of vegan products seems to have grown a lot in the past few years which has made my journey a lot easier.

## Conferences
2020 seems to have been the year of (online) conferences, with almost constantly some conference to look forward to, as speaker, organiser, or attendee.

### Speaking at Decoupled Days
At the start of this year I signed up to speak at the Decoupled Days conference that would take place in New York in July. It would’ve been a great opportunity to have work sponsor a trip to the United States and combine it into a short holiday.

Unfortunately that didn’t quite go according to plan and was instead turned into a virtual conference. Not the trip to New York that I planned but instead a great excuse to work on my home audio/video set-up. After some research I settled on the [Rode Procaster Microphone](http://www.rode.com/microphones/procaster) and [Logitech Brio Webcam](https://www.logitech.com/en-us/products/webcams/brio-4k-hdr-webcam.960-001105.html). 

It was interesting to do a talk for an online conference and definitely different from doing one in-person. My talk and slides about [Open Social’s road to a new headless front-end](/talks/2020-07-23-on-our-way-to-headless-a-transition-in-progress) are available online.

### Organising RustFest
In 2019 [I attended RustFest in Barcelona](https://www.alexandervarwijk.com/blog/2019-11-20-rustfest-barcelona-2019-in-review) and signed up to help organise RustFest in the Netherlands in July of 2020. Little did I know at the time that we wouldn’t be hosting an in-person conference but instead spend another few months to move the entire conference online. I haven’t been able to contribute as much as I had liked but am still proud to have been a part of [a very innovative online conference](https://rustfest.global/) experience that was well received by the community.

### Front-End Conference Galore
As far as conferences that I wasn't an organiser or speaker at, the GitNation team has been hard at work as well this year, organising various online conferences such as React Summit, ML Conference, and GraphQL Galaxy. All interesting and educational conferences I’ve attended this year.

My highlight of these conferences has been GraphQL Galaxy where I’ve been introduced to the [Urql GraphQL client](https://github.com/FormidableLabs/urql) which I’ve excitedly adopted for Open Social’s upcoming chat feature.

Vercel, the company behind the Next.js framework organised their own conference for said framework. It was interesting to hear how others used the framework and to see upcoming features.

## Open Social
As you may know if you follow my blog I work as developer for [Open Social](https://www.getopensocial.com/) —  a startup building community software. This year was exciting as [we managed to secure a 1.25M investment](https://www.getopensocial.com/blog/news-room/open-social-raises-eur-125m-peak-capital-and-nimbus-ventures) to help us build our roadmap. During the year I’ve been slowly completing my switch from back-end to front-end developer (although I still have to build any back-end that new front-end needs myself).

I’ve been happy to be involved this year in the [removal of the features module](https://www.drupal.org/project/social/releases/8.x-8.0), which we shipped at the start of the year and which has drastically simplified configuration management of projects using Open Social.

We’ve also been able to add the exciting [Dashboard feature](https://www.getopensocial.com/extensions/dashboard) using Drupal’s layout builder. Which are in use to build great landing and overview pages such as the homepage of [the United Nations’ SparkBlue platform](https://www.sparkblue.org/).

I’ve spent a lot of time this year on building the basis for [our new Multiverse tool](https://www.getopensocial.com/blog/product-center/how-open-social-creates-multi-sites-platformsh-api) that allows us to deploy and install an Open Social site in any configuration within 15 minutes without any developer intervention. Some work will be needed before we can start rolling the tool out for use by our sales team but it’s been exciting to see the improvements to our internal workflows that we’ll be able to make in 2021.

The last three months of 2020 at Open Social I have spent building a Real-Time Chat. For this work [we’ve adopted ReScript](https://www.alexandervarwijk.com/blog/2020-09-01-my-first-week-of-reasonml) (previously ReasonML + BuckleScript). To make our data available to this new extension we’ve [started work on a GraphQL API](https://github.com/goalgorilla/open_social/pull/1994)that will offer exciting possibilities for ourselves, third party integrators and customers.  It’s all not quite ready for primetime, that’s what the first few months of 2021 will be used for.

A highlight in my personal development was providing a two day workshop on GraphQL to my colleagues at Open Social. In this I shared the knowledge that I have gained in the past year and we focused on how to design and evolve a GraphQL APi, as well as [how to implement a GraphQL API in Drupal](/blog/2020-11-18-graphql-in-the-open-social-drupal-distribution). It was the first time I created both a presentation and group exercises to apply that information. This is definitely something I hope to do more of in the future.

## Wrapping up
2020 has been a somewhat weird year but there’s also a lot to be thankful for. I’m happy that in 2019 I was able to leave my student housing and move into a bigger apartment. This has made this years lockdown a lot more bearable. I’m also thankful for the fact that I’ve been able to easily switch to working from home.

I’m currently enjoying a Christmas Break but look forward to going back to work in January and continuing work on Open Social’s real-time chat and the GraphQL API, as well as starting work on our new front-end. I hope to keep up the higher volume of blogposts that I’ve been lured into by the Blogging for Devs community and expand into some other forms of content production.

Happy New Year! All the best in 2021!



A look at the highlights of what has been quite an interesting year.  Thankfully despite the pandemic there are a lot of things to look back on  positively.  

2020 Retrospective


I’ve been listening to podcasts for a few years now. Mostly doing so while driving. In 2020 I haven’t done as much driving but my podcast consumption has remained relatively the same nonetheless. Mostly while doing house chores or waiting for a some automated process to finish.

In this article I want to take a look back on the podcasts that I’ve listened to in 2020 and, if you haven’t already, why you should check them out in 2021.

## Cortex
<img src="/images/blog/podcasts-2020/cortex-artwork.png" alt="" width="300" />

[Cortex](https://www.relay.fm/cortex) is hosted by [CGP Grey](https://twitter.com/CGPGrey) (who makes [awesome educational YouTube videos](https://www.youtube.com/user/CGPGrey)) and [Myke Hurley](https://twitter.com/imyke) (co-founder of [Relay FM](https://www.relay.fm)) is the podcast that got me started on listening to podcasts (together with Hello Internet). It’s been going since 2015 and it’s probably still my favourite podcast.

On Cortex, Grey and Myke discuss their working lives as independent content creators and discuss productivity, time management and the Apple ecosystem (two steps forward, one step back). If you’re interested in productivity, time management or are just looking for some honest life wisdom then this is a podcast is for you.

## Design Life
<img src="/images/blog/podcasts-2020/design-life-artwork.jpeg" alt="" width="300" />

[Design Life](https://www.designlife.fm/) is a podcast I’ve been listening to since 2017 and it continues being interesting. Following [Charli Prangley](https://twitter.com/charliprangley) and [Femke van Schoonhoven](https://twitter.com/femkesvs) in their design careers they offer insights into their side projects and the things they encounter at work.

They’re not afraid to speak their minds and their episodes make me think about my own career choices and how I spend my time. Besides this they provide me interesting nuggets to think about on the subject of design that I can apply in my own work (as someone who isn’t a designer) and their occasional guest is a great way to discover other talented people.

## My first million
<img src="/images/blog/podcasts-2020/my-first-million-artwork.webp" alt="" width="300" />

This is a podcast I’ve picked up in the past six months. I’ve started listening at episode 1 and am now at episode 50 (published 28 February 2020) with quite some more to go (episode 136 released on December 11th). 

[My first million](https://thehustle.co/my-first-million-podcast/) is hosted by [Shaan Puri](https://twitter.com/shaanvp) (who created a startup that sold to Twitch) and [Sam Parr](https://twitter.com/theSamParr) (CEO of The Hustle). The podcast includes interview with founders who have started a company and made their first million (usually through an exit of some sort). They also contain a lot of episodes with Shaan and Sam exchanging ideas about potential businesses or analysing existing businesses.

It’s a great podcast to improve your own way of looking at businesses, startup ideas and business processes. If you’re someone who thinks a great startup idea is hard to come by, then this podcast is here to change your mind and show you that there are ideas aplenty, you just need to do the work.

## Honourable mentions
Two podcasts that I love but are not actively being produced still deserve an honourable mention for the joy and inspiration they’ve brought me in the past.

### Hello Internet
<img src="/images/blog/podcasts-2020/hello-internet-artwork.png" alt="" width="300" />

[Hello Internet](http://www.hellointernet.fm/) is another great podcast hosted by CGP Grey, this time accompanied by [Brady Haran](https://twitter.com/BradyHaran) (producer of [Numberphile](https://www.numberphile.com/) and [Periodic Videos](https://www.youtube.com/user/periodicvideos)). In this podcast Grey and Brady talk about “YouTube, life work, whatever”. 

This podcast is an honourable mention because unfortunately its last episode was in February of 2020 and I’m unsure if there’ll be more episodes (I certainly hope so). It’s a podcast that is not one to jump into the middle of but if you’re looking for more interesting content (and want to know what a ‘hot stopper’ is) then start at episode 1.

### StartUp
<img src="/images/blog/podcasts-2020/startup-artwork.webp" alt="" width="300" />

[StartUp](https://gimletmedia.com/shows/startup) is created and hosted by [Alex Blumberg](https://twitter.com/abexlumberg) and follows the start of Gimlet media, a podcasting company that has since been acquired by a large streaming service. Although no new episodes will be released for this podcast, it’s been great to follow Alex along on his startup journey, from raising capital to hiring employees and growing the company, up to and including a successful sale of the company.

If you want to start a company then this is a story you must have heard!

## Your recommendations
Perhaps you’ve noticed a trend in the podcasts that I’ve mentioned. For 2021 I’m looking for more podcasts to listen to! If you have something you think I like (or maybe something completely different from what I listen to) then [let me know on Twitter](https://twitter.com/Kingdutch)!

Podcasts have accompanied me for many years now, providing me with new ideas and insights. I take a look back on the podcasts I listened to and which ones I recommend you check out as well. 

My favourite podcasts of 2020

Walking through the creation of the first GraphQL endpoint in Open Social from  module set-up to query resolver. Open Social provides solutions for flexible and engaging online communities. GraphQL in Drupal will pave the way for exciting  new features and external integrations.

GraphQL in the Open Social Drupal distribution

Last week was the first week of actually using ReasonML to build an application instead of looking at Reason theoretically. If you want to know what I’m building you’ll have to keep an eye on [the Open Social blog](https://www.getopensocial.com/blog) but below I’ll take you through my experience.

## Reason vs ReasonML vs BuckleScript vs ReScript
The different names that you encounter when starting with Reason can be quite confusing. ReasonML is the term used by the community to refer to all the tools in the ecosystem. Reason is used to refer to the syntax and the native development toolchain. BuckleScript was the name used for the Reason to JavaScript compiler.

ReScript is the new name of the BuckleScript compiler and a new slightly altered Reason syntax. This change was [announced recently](https://reasonml.org/blog/bucklescript-is-rebranding "BuckleScript is rebranding to ReScript"). The team working on the BuckleScript compiler has decided to break with the native compiler team in order to be able to more quickly provide a compelling language and toolset to current JavaScript-developers.

There is a thriving community for both ReasonML and ReScript. The Reason Discord has focused itself around native development (although there are still some lesser active ReScript channels). The ReScript team has set-up a new Discourse forum where they’ve [included an FAQ](https://forum.rescript-lang.org/t/rescript-frequently-asked-questions/59 "Frequently Asked Questions about the ReScript rename") about the changes.

The current Reason syntax will be supported by ReScript for a while to ensure the community can transition and not create a giant fracture. However, future versions of the Reason syntax may not be supported by the ReScript tools, requiring use of the ReScript syntax instead. Eventually Reason may support compilation to JavaScript again using JS of OCaml but that will be a while away.

## ReScript with NodeJS vs Native Reason
In our investigation to select ReasonML we were heavily focused on client side JavaScript, for which there are already a lot of bindings and tools available for things like Next.js and GraphQL. However, unexpectedly my first ReasonML project involved setting up a GraphQL server. This turned out to be in a bit more in the baby shoes than expected ([although exciting work is being done for Node.js bindings](https://github.com/sikanhe/reason-nodejs)).

With some help from the Reason discord I’ve decided to build the GraphQL server with Reason Native. The biggest hurdle was making sure that Reason could be built and run on Platform.sh which is one of the hosting providers of Open Social. Thanks to the people on Discord we were able to figure out how to do this.

To build the GraphQL server itself I’ve been using [Morph](https://github.com/reason-native-web/morph) which wraps [ocaml-graphql-server](https://github.com/andreas/ocaml-graphql-server) and a webserver together in an easy to use package. It’s been quite a ride to learn how to use [esy](https://esy.sh/) and figure out how all the types work. However, over the course of the week I’ve been slowly figuring out how to deliberately trigger type errors to see what types I’m working with. Knowing what to do with those types is also coming more easily every day and to my surprise I’m even learning to read OCaml by regularly converting small snippets using [Reason Try](https://reasonml.github.io/en/try).

## Onwards
I’ll continue working on the GraphQL server. I’ve been able to create my first connections to the database and my first parts of the GraphQL schema. Along the way I’ve been able to add tests using [Rely](https://reason-native.com/docs/rely/). It feels like a lot of the initial exploring is complete and I can now start duplicating and modifying my initial snippets to add more models and endpoints.

Implementing GraphQL Subscriptions will be an upcoming adventure and will require playing with [some more experimental Morph code](https://github.com/reason-native-web/morph/pull/45 "The pull request to add Websocket support to Morph. This PR is awaiting testing."). Beyond that I’ll be moving on to some work on consuming GraphQL from the same Reason Native application.

In a few more weeks still I hope to be able to start playing more concretely with the improvements that have been made to the ReScript language and start using React with the GraphQL client tools to consume data from our newly built Reason Native GraphQL server. Stay tuned!


A look back on my first week of using Reason to build a native GraphQL  server. Looking at the tools used and the changes in the ReasonML ecosystem.

My first week of ReasonML

A common pattern in React with JavaScript is to extend a component, add a few arguments, modify another and pass on the rest. Sometimes called ‘rest props’ this pattern provides a nice way to provide some default behaviour on top of a DOM element (or an element from a library). 

When trying to do these same things in ReasonML (a statically typed language) I ran into some difficulties. During a discussion in the Reason discord we came up with some possibilities. However, each had their own drawbacks. Let’s explore the problem and the options we have!

## An example in JavaScript

Lets first explore how such a component would look when written in untyped JavaScript. Below is an example of an image element that renders differently based on the assigned variant. An example of where this may be useful would be in a Bootstrap card element to display an image on the left or top of the card.

```js
/**
 * An image with configurable variants.
 */
const Image = (props) => {
  // Pick out the two props we're interesting in 
  // and gather the rest.
  const { variant='top', className, ...rest} = props;
  
  // Assign classes based on the chosen variant.
  let classes;
  switch (variant) {
    case 'top':
      classes = 'image--top';
      break;
    case 'left':
      classes = 'image--left';
      break;
      // etc.
    default:
      throw new Error('Unsupported variant');
  }

  // If classes were passed, append them to 
  // the variant classes.
  if (className) {
    classes += " " + className;
  } 
  // Set our classes and assign any other properties
  // that may have been set by the calling code.
  return <img className={classes} {...rest} />;
}
```

There is quite a bit going on here. There are three things to take away from this code snippet that will be important later.
1. All props that a DOM `img` element supports are supported by our special `Image` element.
2. We consume an extra prop `variant` that is not forwarded to the `img` but used for internal behaviour.
3. We modify a passed in prop `className` that will be forwarded to the image.

## Recreating our Image component in ReasonML

(This method was suggested to me by [Yawar Amin](https://dev.to/yawaramin/comment/hlmm "Component inheritance by Yawar Amin on dev.to"))

One of the things that you see in the JavaScript version of this element is the use of the spread operator (`...`) to catch and release the properties that our special Image element is not interested in. Unfortunately [the spread operator is not supported in ReasonML](https://reasonml.github.io/reason-react/docs/en/props-spread "Documentation on props spread"). The documentation mentions that if we absolutely need it there is a way to mimic the behaviour.

```reason
module Image = {
  type imageVariant =
    | Top
    | Left;

  [@react.component]
  let make = (~variant=Top, ~className=?, ~children) => {
    let classes =
      switch (variant) {
      | Top => "image--top"
      | Left => "image--left"
      };
    let classes =
      switch (className) {
      | Some(x) => classes ++ " " ++ x
      | None => classes
      };
    ReasonReact.cloneElement(children, ~props={"className": classes}, [||]);
  };
};
```

This component can be used in the following manner:
```reason
<Image variant={Image.Left}>
  <img width="400" src="https://images.unsplash.com/photo-1585409677983-0f6c41ca9c3b" />
</Image>
```

When playing around with this, you will notice that it can be a little cumbersome to remember to pass the element that should be rendered as child to the `Image`. This is quite a bit more verbose than the react equivalent `<Image variant="left" width="400" src="..." />`. It also exposes more of the implementation that may be desired (e.g. changing the implementation to use a `picture` element instead of an `img` element would require changing calling code, instead of simply changing the `Image` component).

Another issue is that if you were to set a className on the `img` element itself, it would be overwritten by the classes from our `Image` component. A developer using our component must remember to specify classNames on the outer component.

### Removing the extra element

There is a way to make our `Image` work without having to pass in an extra `img` element. to do this we make use of the `ReactDOMRe.domProps` type that includes all the attributes that are allowed on a DOM element. This can be done by defining `makeProps` directly. Something that is normally done through the `[@React.component]` annotation.

```reason
module Image = {
  let makeProps = ReactDOMRe.domProps;
  let make = (props: ReactDOMRe.domProps) => {
    let classProps = {
      "className": "image--top " ++ Obj.magic(props)##className,
    };
    let myProps = Js.Obj.assign(Js.Obj.empty(), Obj.magic(props));
    let myProps = Js.Obj.assign(myProps, classProps);
    ReactDOMRe.createDOMElementVariadic(
      "img",
      ~props=Obj.magic(myProps),
      [||],
    );
  };
};
```
_Note when using the above code: `let makeProps = ReactDOMRe.domProps;` will copy the entire domProps generation function into your output JS. This may be undesireable._

This element can be used in the following manner:
```reason
<Image width="400" src="https://images.unsplash.com/photo-1585409677983-0f6c41ca9c3b" />
```

This implementation no longer requires the use of an extra `img` element within our custom `Image`. However, as you can see the `variant` property has disappeared. This is a limitation of using the `ReactDOMRe.domProps` type directly. This type does not include a `variant` property. This can be solved by creating a React components for each variant but that duplicates some more logic.

_(Astute readers may also observe that not specifying `className` on our `Image` element would cause the class `undefined` to be added to the list of classes.) This can be solved by checking for its existence making the example a bit more verbose._

Both implementations have some drawbacks, so what are we to do.

## A change of mindset

JavaScript is a weakly typed language. This provides us with lots of creativity. However, typed programming languages [are used for good reasons](https://www.alexandervarwijk.com/blog/2020-01-13-a-comparison-of-javascript-typesystems/ "A comparison of JavaScript typesystems"). They let the compiler catch mistakes before the user is running our application. This means we have to work with some restrictions and can not be as free as in JavaScript when adding a property to our component.

Let’s try to recreate our component without needing a child element while still allowing for our variant class. Instead of extending `ReactDOMRe.domProps` this will require us to spell out all the properties that our `Image` component can handle. This may feel overly restrictive when coming from JavaScript — this article came from a two day discord conversation before I budged from this standpoint — but it also provides some benefits.

```reason
module Image = {
  type imageVariant =
    | Top
    | Left;

  [@react.component]
  let make = (~variant=Top, ~className=?, ~src, ~width=?) => {
    let classes =
      switch (variant) {
      | Top => "image--top"
      | Left => "image--left"
      };
    let classes =
      switch (className) {
      | Some(x) => classes ++ " " ++ x
      | None => classes
      };

    <img className=classes src ?width />;
  };
};
```

This element can be used in the following manner:
```reason
<Image width="400" src="https://images.unsplash.com/photo-1585409677983-0f6c41ca9c3b" />
<Image variant={Image.Left} src="https://images.unsplash.com/photo-1585409677983-0f6c41ca9c3b" />
```

This brings us back to the simple calling convention of a single component. This means if we wanted to we could easily implement our Image component as a picture element without changing any of our calling code. Our Image component also supports our variant property which is not passed on the the img element.

I would like to argue that being this explicit about the properties that our custom component accepts is a good thing. If we run into a situation where another property must be supported it’s relatively trivial to add. In addition, if we decide that we should not support some properties then these can be easily removed from the component. For example in case this image component should not have a `width` property because it must always be full-width, when removing the property the Reason compiler will tell us of any location in our application where it was used, forcing us to find a solution.

My problem of trying to add an optional prop to all the other possible properties of an image element started when I tried to recreate the behaviour of the [Bootstrap card component](https://getbootstrap.com/docs/4.0/components/card/ "Bootstrap V4 card component documentation"). The layout depended on classes on its child elements. In this article I’ve shown a couple of ways how you could get to such behaviour, each with their own trade-offs. 

While writing this article I’ve had some ideas of how you could utilise Reason’s type-system to implement component nesting as used in Bootstrap cards in a different way altogether. I hope to explain this in a future article.

Have you run into this problem already? How have you solved it? Do you see any ways to improve any of these solutions? Let me know on [Twitter](https://twitter.com/Kingdutch/ "Find me on Twitter!")!

_Thanks to alex.fedoseev, yawaramin, jaap, ryppy, johnridesabike, davesnx for their feedback in the ReasonML discord and their patience while I asked endless questions. Thanks to [Yawar Amin](https://dev.to/yawaramin/ "Read Yawar Amin's great articles about ReasonML and oCaml on dev.to") for providing feedback on a draft of this article._


Moving from React in JavaScript to ReasonML can be quite challenging. Figuring out how to move your existing code patterns from JavaScript to a strong type-system takes some time. In this article we'll explore how to translate a common component extension pattern.

Mindset for ReasonReact components

In a previous blogpost I’ve [compared plain Javascript, TypeScript, Flow, and ReasonML](/blog/2020-01-13-a-comparison-of-javascript-typesystems/). I ended the article with a recommendation for using ReasonML in your new React projects. In this article I want to answer some questions that you may have about adopting ReasonML for React projects.

## Does it work with Next.js?

Next.js is the standard for server-side rendering (SSR) with isomorphic components (components that are the same client and server side). Thankfully, some people have gone ahead and provided examples for using [ReasonML for components](https://github.com/zeit/next.js/tree/canary/examples/with-reasonml) as well as [for custom server side logic](https://github.com/zeit/next.js/tree/canary/examples/custom-server-reasonml).

There is [an open issue about combining the two Next.js examples](https://github.com/zeit/next.js/issues/7326) that links to some outstanding tasks. However, the underlying problems that the issue refers to have been fixed at the time of writing this.

This means that if you were planning to use Next.js in your React application, this won’t stop you from adopting ReasonML.

## Does it work with GraphQL?

One of the advantages of ReasonML is its static typing. This can be especially powerful when combined with type information from your data source. To make this work requires clients that are able to consume this type information and make it available in your ReasonML project.

For GraphQL, the most popular client, Apollo, provides [ReasonML bindings](https://github.com/apollographql/reason-apollo) from their own GitHub organisation. It being in the main Apollo GitHub repository gives some assurance that it will be supported in the future. 

What makes this exciting is that GraphQL itself is also strongly typed. The Apollo client can consume the GraphQL schema and make this available as types that can be checked in your application at compile time. This also gives you strong guarantees that you’re properly handling information that’s optional and may not be returned from the server.

## Does it work with JSON:API?

An alternative to GraphQL that is heavily used in the Drupal ecosystem is JSON:API. This is another layer on top of normal JSON requests that provide information about schema’s. 

[A medium article](https://medium.com/@sharifsbeat/fetching-data-in-reasonml-pt-1-c06f3cc6b250) outlines how to use ReasonML bindings for `fetch` and a Reason JSON encoding/decoding library to consume a JSON data source. Although not directly making the JSON:API schema available in your type-checked code, these tools do ensure that you properly handle the success and error codes for the request and the availability of fields in the returned JSON.

## Can we reuse community React components?

One of React’s strengths is its component hierarchy. This model that makes rendering so efficient, also enables the React community to create and share re-usable components. It would be very inefficient if none of these community components could be used on Reason applications.

Luckily for us, Reason was created with a big focus on [interoperating with existing Javascript code](https://reasonml.github.io/reason-react/docs/en/components#interop). This allows to consume existing components in a Reason application. Another option is to write components in Reason code and publish them for consumption using Reason as well as with other typing systems or plain Javascript. The [genType tool](https://github.com/cristianoc/genType) can help in creating TypeScript or Flow typing information from ReasonML code.

## What about the community?

Community around a project is very important. It dictates the development and improvement of tools, as well as the ability to get help for more complex projects. The Reason community is still a bit smaller and younger than the communities behind alternatives like TypeScript. However, in my personal initial contact the community has been very friendly and provided a wealth of links on where I can find information.

One of the goals for 2020 is to collect all the scattered information about Reason, ReasonReact, BuckleScript, esy, dune, etc. onto a single documentation website: [Reasonml.org](https://reasonml.org/).

If you want to chat with people that are using Reason already, be sure to [join the Reason discord](https://discordapp.com/invite/reasonml).

## Can we use styled-components?

Styled components is a great solution for styling React components. Unfortunately styled components doesn’t translate well to ReasonML. Styled components allows arbitrary arguments which makes it hard to match with a static typing system. 

There are other solutions. Both fully typed which go away from writing actual CSS, as well as systems that allow you to write actual CSS strings.

Moving to a fully typed CSS solution may make it more difficult to onboard someone on the front-end who only knows HTML/CSS. However, with any Javascript based front-end you’ll need more knowledge than plain CSS anyway so this may be a moot point. The advantage of static typed CSS can be better code-completion and validation for people less familiar with CSS (arguably you’ll need to know both in any scenario).

A large part of the web is moving to utility classes which fits well into Atomic 
Design and forces a good separation of concerns. You can 
[read the article that convinced me](https://frontstuff.io/in-defense-of-utility-first-css) for more info on utility based CSS.

## Can you show me a video about why ReasonML is great and works well for React?

[Absolutely, here’s the maker of ReasonML and React on the subject.](https://www.youtube.com/watch?v=5fG_lyNuEAw) If you’re short on time I recommend watching at least the first 10 minutes. Hopefully that’ll convince you to also watch the other 20.

## Conclusion
Hopefully at this point, your questions about working with ReasonML have been answered. If you want to get started with ReasonML, I recommend starting with [the Reason documentation](https://reasonml.github.io/docs/en/installation). Be sure to keep an eye on [Reasonml.org](https://reasonml.org/) too to see the information about the Reason ecosystem being brought together in one place.

If you have any questions about adopting Reason that are not covered above, [let me know on Twitter](https://twitter.com/Kingdutch/) or [ask me on the Reason discord](https://discordapp.com/invite/reasonml).


When evaluating ReasonML for use in your React project you may have some doubts. Fear not! You can do the things you could do without ReasonML, but better!

Start your next React project with ReasonML

A look at JavaScript, TypeScript, Flow, and ReasonML for their suitability in Enterprise applications.

A comparison of JavaScript typesystems

_This article was originally published on my Explaining Crypto blog in early 2018._

In 2017 blockchain earned its spot in mainstream media. Simultaneously we reached the height of the ICO craze: simply saying that you were doing an ICO often resulted in money being thrown your way. In this article we’ll take a look at the technology behind the buzz and see whether it’s here to stay (spoiler alert: it is).

## A central source of truth

Money was once invented to make it easier to store the value that you owned. Instead of having to figure out what you want for your service or goods right this moment you could take a token instead. This token could then be used at a later point to show others you had provided some value that you could then trade in for goods or services.

Banks were created to provide an easy way of storing larger amounts of these tokens and making it easier to send them over a large distance. Instead of physically shipping a large amount of money one could bring it to a bank and have the bank send a cheque by mail or telegraph.

Banks could thus be used to send money from one party to another over a large distance. In this process the bank acted as a trusted third party. They confirm that they received the payment from one party and then that they have delivered it to the other.

Acting as a trusted third party requires some effort by the bank (although nowadays most of this is automated). This in turn is offset by transaction fees that are charged by the bank to the parties transferring value.

To ensure that banks know whether one party can actually send money to another they use what is called a ledger. This ledger serves as a record of transactions that have occurred and serves as a central source of truth.

Not all transactions lend themselves to being executed through a bank. Take cryptocurrencies for example, a relatively young technology with a lot of banks uncertain about how to handle money  related to it. Furthermore, the transaction costs can be a significant barrier to usage. 

To overcome these obstacles - availability of a trusted ledger and the associated transaction costs - an alternative was found in the form of blockchain.

## A distributed ledger

The technology underlying blockchain is named “distributed ledger technology”. In transactions on a blockchain this distributed ledger takes over the role of the bank’s ledger as a central source of truth. It allows all parties involved to see whether a transaction is possible.

When someone wants to add a transaction to this ledger then the transaction must be approved by all participants in the ledger. No special technology for this would be needed. We could all take a piece of paper, write down the transaction with our date and signature and we’d have a distributed ledger. 

This method of manually recording a distributed ledger is rather inconvenient. To verify the ledger we would have to come together and compare all entries on all pieces of paper. Comparing all transactions and ensuring they each have the correct date and signature.

## A cryptographic replacement

Using cryptography instead of our own physical signature we can digitise the paper copies of our ledger. Instead of a date and personal signature we devise a system that creates a unique value for the data we want to store on our ledger.

Taking the most well known cryptocurrency, Bitcoin, as an example. Each entry on our ledger contains a set of transactions, named a block. 

Just as a bank would, first we check for each transaction whether it’s actually possible (does the sender have the required funds and does the recipient exist). We then simply discard any transactions that are invalid.

## A chain of blocks

From the valid transactions we then calculate a single unique value using a cryptographic hash function. A cryptographic hash function takes some data as input and transforms it into a value that is unique for every combination of inputs.

The trick of chaining the blocks together happens at this point. Instead of only taking the transactions that we want to encode on our ledger, we also take the computed hash of the previous block (entry on our ledger) as input for our next hash.

By using the unique property of a hashing function that it’s output can only be produced by a single set of input data, together with the dependance of each block’s hash on that of the previous one, a verifyable chain of blocks is produced. To verify our ledger we would simply calculate the hash for each block and ensure that it matches up with our recorded hashes. 

If someone were to insert a transaction into one of the blocks, its hash would change, breaking the chain.

##  A gentleman’s agreement

The principles of how a blockchain works are relatively simple. Ensuring that all the involved parties agree on which transactions should be included in a block is quite a challenge. The two prevailing methods on how to create consensus on the transactions that should be included, proof of work and proof of stake, will be covered in a future article.

The possibilities that blockchain technology provides in enforcing agreements between two parties using smart contracts will also be covered in a future article.

## A look at the future

Although it won’t be as easy to raise money with an ICO as it was in 2017 (this is a good thing), blockchain technology is here to stay. The obvious application of a digital currency has been tried and tested. Blockchain will find its mainstay in more niche applications solving large enterprise problems such as chains of custodies for products or evidence.

A big hurdle will probably be government legislation. Keeping up to date with technological advancement is a challenge for all individuals. Even more so for a large group of individuals that are expected to govern for the future. I do believe proper legislation is necessary to protect the general public from scams and money-grabs while allowing legitimate projects to flourish. 

One project that is experimenting with a new form of ICO which promises better accountability and governance is The Abyss. Their Distributed Autonomous Initial Coin Offering (DAICO) is something that could provide a solution to these problems.


Blockchain has been around for a while. The hype seems to be coming to an end as it moves to a more mainstream phase of the technology lifecycle. Lets take a look at what Blockchain actually is.

What is blockchain?

RustFest Barcelona 2019 was the first time I attended a Rust conference. I've previously been to a few editions of DrupalCon as well as React.Amsterdam so I have something to compare the experience with. However, RustFest was a unique experience compared to the previous conferences I attended.

RustFest Barcelona was only the 6th edition of the conference. The first edition was [held in 2016 in Berlin](https://blog.rustfest.eu/past_events/). This makes it a relatively young conference (compared to [DrupalCon's 14 year track-record](https://www.drupal.org/association/drupalcon/locations#2005) for example). There were around 400 attendees in Barcelona. This made for enough people to be able to meet new people in every coffee or lunch break and yet was not too big to find a friendly face.

## Why Rust?

If you're already convinced that Rust is your systems programming language of choice then it's safe to skip this section. However, whenever I talk about Rust this is one of the first questions I'm asked, so it's worth addressing.

The [Rust project homepage](https://www.rust-lang.org/) actually summarises Rust very well: Rust offers performance, reliability and productivity. Rust is just as fast (and sometimes faster) as C and C++. The language got popular for its type system which prevents memory safety issues. Microsoft recently published [an article](https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/) that shows 70% of the issues that the Microsoft Security Response Centre assigned a CVE (Common Vulnerabilities and Exposure) number to were caused by memory safety issues. Rust's type system was built to prevent these issues.

There is one thing in the survey that caught my eye and describes what I like about the language better than the marketing bullet points. The Rust typesystem offers many tools to write correct code. It ensures that you handle error conditions and if used correctly forces you to cover every code path. I talked about this briefly in my DrupalCon 2019 talk "[Multilingualism makes better programmers](https://www.alexandervarwijk.com/talks/2019-10-30-multilingualism-makes-better-programmers-a-look-beyond-php-and-javascript/)".

> According to an internal survey, the top reason for adoption was “correctness” - an extension of Rust’s safety guarantees that work towards making true the adage “if it compiles, then it works”. — <cite>Why Rust for safe systems programming, MSRC Team (2019)</cite>

## Two days of talks and workshops

RustFest Barcelona was held on Saturday the 9th and Sunday the 10th of November 2019. The conference being held in the weekend made it easy to attend the conference without having to take days off from work. Unfortunately I don't work with the Rust language in my day to day programming so having the trip sponsored by work was not an option. I think roughly half the people I met at the conference were working with Rust currently. Attendees that had been to previous RustFests noted that this number was steadily increasing :)

Although I've been to conferences before, RustFest was the first conference I attended that included workshops in the ticket price. The conference was divided into two parts each day. The mornings comprised a single track of talks in the auditorium. The workshops were held in the afternoon and provided the choice of both single-day workshops as well as workshops that spanned both days. I attended [the workshop of Luca Palmieri](https://github.com/LukeMathWalker/ndarray-koans) about using the [ndarray crate](https://docs.rs/ndarray/0.13.0/ndarray/) to implement a K-means clustering algorithm.

The talks that were given were all excellent. Covering a broad range of topics suitable both for beginners as well as more advanced users. Some highlights for me personally were a talk about [adopting Rust at Microsoft](https://barcelona.rustfest.eu/sessions/r-evolution) which can be useful if Rust ever needs to be sold inside of your own organisation. An introduction to [D-bus and the Rust D-bus library](https://barcelona.rustfest.eu/sessions/zbus-yet-another-d-bus-library) was also very interesting. The story of [how the Rust compiler ships a new version every 6 weeks](https://barcelona.rustfest.eu/sessions/shipping-a-compiler) without breaking every project using Rust is something that any software company can learn form.

The talk by [Katharina Fey](https://twitter.com/spacekookie) deserves its own paragraph. She held a passionate speech about [the human cost of development](https://barcelona.rustfest.eu/sessions/human-cost-of-dev). Going into detail on why people get burned out as well as why our current corporate view of recovery is wrong. We should instead adopt a more human centered approach to burnout recovery. I tweeted [about](https://twitter.com/Kingdutch/status/1193492840518733825) [this](https://twitter.com/Kingdutch/status/1193497701813489665) [already](https://twitter.com/Kingdutch/status/1193505350068121600) but everyone should watch (or read the transcript of) her talk, no matter your function, no matter your industry.

## A welcoming community

I arrived in Barcelona late on Friday evening and was at the conference about half an hour early on Saturday morning. People were waiting outside to pick up their badge and enter the conference. Many were happy to engage in conversation, tell me about their own experiences and asked me about mine. The day of talks and workshops flew by. There were no organised after-conference activities but at the end of each day people used Discord and Twitter to group up and spread out across Barcelona.

Unfortunately I had to return to the Netherlands on Monday morning and was unable to attend the impl days where attendees work on Rust projects together. However, I did sign-up to be involved in organising [the next edition of RustFest](https://netherlands.rustfest.eu/) which will be held in Q2 of 2020 in the Netherlands!

I very much look forward to seeing all the people I met in Barcelona once more.


This year was the first time I attended RustFest. The European conference for the Rust Programming language. I take a look back at the experience.

RustFest Barcelona 2019 in Review

Drupal made a huge stride with the adoption of Twig and the abolishment of its custom templating solution. However, while the Drupal community has been focused on improving the experience for tightly coupled front-end output, the rest of the web is moving steadily in the direction of a more decoupled set-up with Javascript front-ends enabling more advanced user interactions.

Adopting new technologies or ways of working in existing projects is never easy. In this article, I will explore some of the challenges that the Drupal community faces in the adoption of React as a front-end technology.

<h2>A different set of skills</h2>

One of the things that I've noticed as a member of the Drupal community, is that the skillset of a front-end developer is a lot different within Drupal than outside of it. 

As a front-end developer working with Drupal you need knowledge beyond HTML and CSS and require a good grasp of how Drupal's theming layer works. For example: how do you use Twig in a performant manner and when should you use templates vs render arrays and alter hooks? In addition, with Drupal's State and AJAX APIs, a lot can be accomplished without writing any Javascript.

Outside of Drupal, a front-end developer still requires the same knowledge of semantic markup and accessible styling. However, with most of today's popular front-end frameworks relying heavily on Javascript, it's a necessity to have a good grasp of the language.

It is interesting to see how moving in either direction requires new learning. A large impediment for the adoption of React (or other Javascript front-ends) in Drupal will be a mismatch in the skillset of the teams within companies. Any Drupal developer can figure out how to create a new form with the Form API that can be handed to a front-end developer for some styling. However, in a React world, a bigger chunk of the work will need to be performed by front-end developers. This will require either retraining of existing staff or new hires.

<h2>Decoupling data</h2>

One of the points raised in a BoF at DrupalCon Amsterdam is [Drupal's focus on the JSON:API](https://dri.es/headless-cms-rest-vs-jsonapi-vs-graphql). With the inclusion of the JSON:API in Drupal core it has become the standard for Drupal installations. It's now the first thing that people exploring decoupled Drupal will see. Even though there is [great support for GraphQL in the contrib space](https://www.drupal.org/project/graphql), the inclusion in core means that the most resources will now be allocated to the JSON:API.

This decision is in sharp contrast with that of the React community. Pushed by Facebook, GraphQL is the de-facto standard with [multiple](https://relay.dev/) [libraries](https://www.apollographql.com/) that offer great support. Any innovation that is done in the space of data fetching and data management with React will first and foremost be implemented using GraphQL.

This split of direction, with React focused on GraphQL and Drupal focused on JSON:API, means that any advancements made by the React-GraphQL community will have to be remade, in large part, by the Drupal community.

<h2>What about sitebuilders</h2>

One of Drupal's goals has always been to allow sitebuilders to do as much as possible without writing any code. This could be considered a precursor to the no-code movement that is rapidly gaining in popularity. Through extensions such as the Field UI and Views, a lot of the flexibility of Drupal can be wielded by non-programmers. These systems benefit greatly from Drupal's tight coupling between front-end and back-end. This coupling is what allows each element to describe how it will need to be displayed once configured.

Although it is a tremendous strength for Drupal, this flexibility that is offered to sitebuilders also poses a barrier for moving to a decoupled set-up. Decoupling means moving to a system where Drupal only serves as a data layer that exposes an API. This change then only covers one part of the tools that sitebuilders require. To fully embrace React and say goodbye to Twig, a lot of work will have to be done to make React just as flexible as the current Twig set-up is.
 
To support a system where Drupal and React can still offer its full potential to sitebuilders a lot of work will need to be done. This need increases the time that Drupal will require in fully embracing a decoupled-first set-up. 

<h2>Conclusion</h2>
 
The landscape of the Web is ever-evolving. This newest change poses a lot of opportunities to create even more engaging user experiences. However, it also poses challenges for incumbent users of Drupal and its ecosystem. Businesses will have to figure out how they will deal with the shift in required skills. Drupal will need to evaluate whether it is worth embracing a technology that is different from what a majority of other React users are using. Finally, we'll have to work hard to ensure that we don't leave behind an important target audience for Drupal as a Content Management Framework.

What do you think of the move to React? What are the biggest challenges that you face? Discuss this article with me <a href="https://www.twitter.com/Kingdutch" title="My twitter profile">on Twitter</a>. 


With the move to decoupled applications and the adoption of frameworks like  React and Vue.js, the workload of front-end development in Drupal will change.  A different skill set will be required and the community will have to adjust as  a result.

The future of Drupal front-end development


The desire to have a place on the internet that I can call my own still exists. A place where I can write out my thoughts, without the fear of my content being suddenly removed because the platform I publish on decided to change their policies or go bankrupt.

I've tried this before. Setting up a Drupal website. Something that's not difficult to do after working with the platform for almost 10 years. However, adding all the little things that you might need for a properly optimised blog can distract from actually getting to writing content. I've also tried to write something using React. In those endeavours I usually get sidetracked into building out yet another CMS, figuring out server side rendering, etc. All these attempts are very educative, usually discovering how existing tools work, why people use them over rolling their own and how I could be using them. This distraction does mean that they're never really productive towards achieving the goal of making sure that my website is not just a DNS error or a page not found.

Now, in an attempt to actually ship rather than only learn, I've set up [Gatsby](https://www.gatsbyjs.org/) which gives me an easy framework on top of React to render out content. After reading some reviews I've decided to give [Netlify](https://www.netlify.com/) a try for simple, free, hosting. So far I'm impressed with what I see and the amount of configurability that they provide. While researching hosting I came across [Netlify CMS](https://www.netlifycms.org/) which seems like a great way to allow simple content management with a git backend. I love Markdown, but I find I just can not write articles in PHPStorm, no matter how much I love Jetbrain's IDE for coding.

I first started with the [Gatsby + Netlify CMS Starter](https://github.com/netlify-templates/gatsby-starter-netlify-cms). After setting up I found that I had to remove most of what they gave me out of the box. As I'm not very familiar with either Gatsby or Netlify CMS I found that this meant that I was mostly battling the magic glue. However, it's easy to get started with Gatsby so nuking everything and starting over was quickly done. With the [Gatsby Netlify CMS plugin](https://www.npmjs.com/package/gatsby-plugin-netlify-cms) and the experience from the Netlify tutorial setting-up the Netlify CMS once more was a piece of cake.

So here we are, again, a new blog started. The editor experience of Netlify CMS feels very nice. With live preview, all the WYSIWYG tools that you want and an easy way to add extra fields for SEO or other pruposes.

All that's left to do now is to build out the actual front-end of the blog. Although the Gatsby starter gave me that for free, it also made some tech choices for React that I disagree with (I prefer styled-components over SaSS for example). Lets see if I can ship before I get distracted by the rabbit hole of development.


Everyone should have their own place on the internet. In this post I talk about revamping my own spot on the web with a quick tour of the technologies that I'm using.

Posts