Netlify functions provide a very convenient way of working with AWS Lambdas, and they have an impressive array of example use cases, such as sending emails, processing payments and logging.

This example reads secrets from environment variables (to avoid them being exposed in the browser), but it is mostly generic, and can be adapted for other use cases easily.

Step 1 - Prerequisites

• Create a repository for the code, probably on GitHub
• npm i -g elm
• npm install -g netlify-cli
• npm i -g create-elm-app

Step 2 - Create vanilla Elm app

• create-elm-app elm-app-with-netlify-function
• cd elm-app-with-netlify-function
• elm-app start

This should start a development server and load the app in your browser.

You can look at this commit in the companion repository to check that everything is ok.

Step 2 - Deploy on Netlify

• npm init (and fill in sensible values)
• npm i create-elm-app --save-dev (this adds create-elm-app to package.json, which is used by netlify)
• Push the code to GitHub

You can see the results of this at this commit in the companion repository

• Log in / Sign up / register with Netlify
• Create a new site on Netlify
• Choose your repository
• Set the "Build command" to elm-app build
• Set the "Public directory" to build
• Click on "Deploy Site"

Netlify will now deploy the site, installing the dependencies specified in package.json, then running elm-app build and then serving the dist directory.

From now on, Netlify will attempt to deploy the latest code every time you push to GitHub.

Step 3 - Link Netlify Dev

• netlify login
• netlify link and choose the “Use current git remote url” option
• Add “./netlify” to .gitignore
• Add a netlify.toml file (from this commit in the companion repository)
• netlify dev

This should start a local development server and load the app in your browser, in a similar way to step 1.

Step 4 - Add a netlify function

Run netlify functions:create to create a new netlify function. Choose the “js-token-hider” template, and name it "call-api".

This will create a javascript file for the function, and a package.json for its dependencies in “functions/call-api”.

Replace functions/call-api/call-api.js with this one in the companion repository

Now if you run netlify dev, the function will be served as well as the app, albeit on different ports. You can view the function in the browser to check that it is working (probably at http://localhost:34567/call-api or http://localhost:34567/.netlify/functions/call-api)

Step 5 - Call the netlify function from Elm

Install depdencies

• elm install elm/json
• elm install elm/http
• elm install krisajenkins/remotedata

Update Main.elm to call the function and display the results (from the companion repository).

Instruct create-elm-app to proxy api calls to the function, by adding elmapp.config.js, as shown in the companion repository.

At this point, thee application runs, and successfully calls the api, but there are no secrets / environment variables yet, so the UI shows an error.

Step 6 - Add the secrets

Go to the “Site Settings” - “Build & Deploy” - “Continuous Deployment” - “Environment Variables” section on the Netlify website for your application.

Add environment variables for API_TOKEN and API_URL

Now when you run ‘netlify dev’ the app should now load in the browser and call the locally hosted netlify function, which will return the API_TOKEN and API_URL environment variables that you set on Netlify.

The same should be true on the live deployment on Netlify. You may need to “Trigger Deploy” manually on Netlify, so that it uses the new environment variables.

You can see the deployment of the companion repository at https://netlify-functions-with-elm.netlify.com

Conclusion

Netlify / serverless functions are extremely useful for creating / connecting to the backend services that your front end needs. They are also very east to set up, as this artcile (hopefully!) shows.

Create-elm-app is a great tool for developing Elm applications, and its simple proxy feature works well when developing Netlify functions.

Netlify Dev is great for replicating the production Netlify setup when developing locally (in this case by automatically providing the environment variables).

In Elm, there are a lot of great ways to scale the Model, and update, but there is more controversy around scaling the view. A lot of the debate is around Reusable Views versus Components. Components are not recommended, but a lot of people are still advocating for them. This article presents an idea that hopefully strengthens the argument for Resuable Views.

In almost all cases, the scaling problem comes down to enforcing consistency, which usually means allowing child views to make some adjustments to the master view, while at the same time not allowing child views to make a mess.

I will be using Richard Feldman's excellent Real World app (specifically written to demonstrate scaling in Elm) as an example, as it is contains a lot of current best practice techniques, it is well known (2000+ stars and 300+ forks) and Richard is a well known Elm expert.

I will be suggesting some improvements to this code, so I want make a clear at this point that I mean no disrespect by this (I would bet large sums of money that he did it in about one tenth of the time it would have taken me!). You could also argue that the problems are small and not worth fixing. Ultimately, this decision is yours, but by the end of the article I hope to persuade you that there are problems, and that they are fixable if you think it is worthwhile.

Master view functions with conditionals

One option is to define a master view function. This function takes care of shared concerns, like the header bar and overall layout. Then it calls child view functions depending on the current view and / or has parameters to control child specific behaviour.

This works, but can quickly lead to:

• An explosion of parameters, potentially forcing your child views to return a lot of things they don't care about.
• A mixing of responsibilities between master and child views.
• Extra code and duplication.

In the Real World App, a parameter of type Page is passed to the master view so that it can render a navbar link as active. There is a large case statement that uses this parameter to work out what which link is active, and it would be a lot easier for the child just to specify this.

The line below shows the master view passing Page.Home, which has to match up with Home.view home. This is easy to get wrong, there is no help from the compiler or type system, and really it is the responsibility of the child view the specify this.

viewPage Page.Home GotHomeMsg (Home.view home)

There is some duplication when creating the NavBarLink Html, and the linkTo function will accept any Html, although only very particular Html is valid.

Convention and trust

Another possibility is for child views to be responsible for keeping shared elements consistent, by convention and trust.

Arguably this also happens in the Real World App. The Home, Article and Profile views all have the concept of a banner. The banner is different in each view, but presumably is meant to be a consistent and recognisable visual element (essentially, it's the title / header for the view). The views don't share any code for these banners, and as a result of this they are not the same size or colour. You could theoretically try and enforce a convention using tests, but it would be difficult, and probably not worthwhile.

Helper functions

Another possibility is for child views to be responsible for keeping shared elements consistent, but by using some helper functions. This is definitely a step forward, and is probably the most common solution I see in the wild. The functions can go in the same file and be next to each other. This makes it easier to see that they are related and are representing the same visual element, and easier to make them consistent.

However, there are still some drawbacks. The main one is that the child views have to know to use the helper functions, and there is nothing enforcing this. This isn't a huge deal when you only have one shared element and one function to call, but as applications get bigger, you end up with a combinatorial explosion of differences in the shared visual elements. Most people tame this by providing a number of small, focused functions for the various differences. Then the child view has to know about all these functions, and how to compose them, and there no help from the compiler.

Again, this arguably occurs in the Real World App: for example in this part of the Profile.view function, which needs to know how to use the viewTabs, Feed.viewArticles and Feed.viewPagination helper functions, and what Html they need to be contained in.

Scaling with Master View Types

In order to overcome these problems, I propose using a Type to define your site structure (I rather pompously call this a "Master View Type"). Child views then return this type, and the master view takes it as a parameter and returns the html.

For the Real World App examples we have been looking at, the Master View Type is below (Viewer is the person viewing the page in the Real World App). You could arguably have more general banner types here, such as AvatarBanner, or even IconBanner (instead of ViewerBanner) depending on your domain.

type alias Page =
    {   activeNavBarLink: NavBarLink
        , banner: Banner
        , body: Html Msg
    }

type Banner =
    TextBanner TextBannerProperties
    | ViewerBanner Viewer
    | ArticleBanner Viewer ArticlePreview

type NavBarLink =
    NavBarLink NavBarLinkProperties

To demonstrate this, I have create a repository with just the Header and Banner parts of the Real World App and then created a new repository after refactoring to use a Master Page Type, NavBarLink Type and Banner Type. You can peruse the code to get a feel for how it works.

To my mind, using a Master Page Type has the following benefits:

• Writing the master view code is easier
• Writing the child view code is easier
• Communication and understanding are improved, as UI concepts now have names
• Theming / redesigning a site is a lot easier
• Elm packages can provide UI templates

The master view can precisely define what it will accept / support via the types, with union types and opaque types. Non supported combinations can be made unrepresentable or uncreatable.

In my example repository the NavBarLink type is opaque, so it is only possible to create supported NavBarLinks (home, article and viewer). In a similar way Banner is a union type, which means that only supported variants can be represented.

It would be possible for a programmer to simply change these files, but a proficient programmer would recognise the patterns and follow them. If this isn't enough and you are feeling paranoid, then you can require stricter code review on such files, potentially taking advantage of CODEOWNERS functionality on GitHub and GitLab. In the extreme you can provide the modules via an elm package, and restrict push access to the underlying repository.

Child views don't have to do anything more than create an instance of the types. The helper functions all return types, so it's easy to see which functions can be used in a particular context, and is impossible to use functions in the wrong context. For example, if a function returns a HeaderBarLink, it is impossible to mistakenly use this function to create a link in the FooterBar, or elsewhere on the page. Child views can also leave some of the complexity to the master view. For example, the child view can define a list of options to choose from, and the master view can render this using buttons, a drop down list or an autocomplete list, depending on the number of options.

The master page type also provides names for UI concepts, which can then be discussed. For example, a designer could say "Let's move the NavBarLinks to the left hand side", and everybody would know what they meant. A product owner could say "Let's create a new page with an IconBanner, and we'll use the current weather api for the icon" and again, everybody would know what they mean. You can look at this excellent thoughtworks article for more details of this.

Since the responsibility for turning the Master View Type in to html is all in the same place, it is easy to make drastic changes to the look and feel of a website, and to do theming. These changes and themes can alter the Css and the Html, which is something that the normal theming techniques just can't do. Pragmatically, your Master View Type will often have a body: Html Msg property (to allow child views complete flexibility on the child specific parts of the page) so there would still be some sprawling code to fix up, but it will definitely be a lot easier.

Finally, it opens up possibility of providing ready made themes and site layouts as packages. This would allow you to just do the following to get a working app, complete with layout and styling:

• create-elm-app
• elm install elm-bootstrap-starter-template
• Write some code to create the Master Page Type
• elm-app start

Companies could create packages like these to ensure a consistent look and feel across their applications. Open source designs and layouts could emerge and become commonplace, similar to the way that Bootstrap has revolutionised html and css design. Developers with limited design skills (like me) could concentrate on the the bits they are best at (the logic), but still produce produce elegant websites using these packages.

To demonstrate this I have created a bootstrap starter master view package. It mimics the layout and design of the bootstrap starter template. I have then used this package in a demo elm application. You can browse the demo application to see how it looks, and view the source to see how it works.

All these advantages come at a small to negative cost. There is a little more code for the new types, but some duplication is removed. You can view the source of the Real World App repositories from before and after refactoring to use a Master Page Type for the full details.

Conclusions

Master View Types bring a lot of benefits (view code is easier to write and maintain, UI concepts are named and UI packages are possible) for little or no cost. They should improve the code of any Elm application that has issues around enforcing consistency (while allowing flexibility) in their view code, which in my experience is most medium and large applications.

Tears of joy from a developer who got to build a PWA

Growing up, being movie director was what my werewolf teeth were made for. Who knew that this front-end thing was gonna consume me like this. But it’s all good because creating art that actually helps people might be the one job to rule them all.

I’ve been enjoying it since the days when Flash was one of two ways to have rounded corners on screen. I was the happiest when I was able to demonstrate that the web can be a source of delight.

And since then it’s only been getting better.

Nowadays however, I’ve observed how companies still prioritize native app development. I need to show how the web, too, is ready for the amazing mobile experiences.

In my own circles, I am known as the guy who invests irrational effort in animations and performance. To me, the prettiest thing in the world is nothing without well crafted transitions narrative that helps guide the visual experience.

Recently I got handed an opportunity that was dear to my heart. It would allow my users feel when using it, the way I felt when creating it.

Meet Dscova.com — the platform that lets us openly share and brag about our experiences worth enjoying.

It grows, it shrinks, it dances, it slides, it gets excited when you touch it. And should you choose to add it to your home screen, it’s gonna follow you forever. It’s your overly attached web app that you are not ashamed to introduce to friends.

One thing that is clear is that it doesn’t blindly follow any design guideline. It has it’s own unique tone. We have mi hombre Diego to thank for that. I love working with designers who bring their own perspective.

Dscova should be the definition of everything I was convinced was possible on the mobile web. It’s my favorite baby thus far. Wish I could call it George.

Do you notice? I too am not following the almost strict guidelines of delivering app shell. Instead, I’m embedding a splash with the initial response from the server. This is how I’m able to let the users know that they’re in the right spot, in a quick, yet smooth way.

OF COURSE I understand that many of the big guys take the app shell approach.

But if you are like me, you are almost pissed off too when you’re faced with a useless/broken UI for seconds at a time.

I am convinced that the slowly fading splash prepares the user in a better way for the well known app behavior that always comes after a splash.

Demoing Dscova around, I’ve had casual users forgetting they were on the web. Not surprising, since they care for the experience, not the platform.

So I’d like you to drop everything and come join the wave. Especially if you turn out to be one of the artists that have ever delighted me on my phone.

I’m aware that you might be reluctant to make this transition today. As big and undisputed you think the current app stores are, imagine how sooner or later, the web itself is gonna turn into an app store, without the store part. No landing pages. Just apps that integrate with the OS and with each-other.

If you consider today’s users as lazy and aware of their time, hold your breath for the unexpected complaint:

“I had already opened their app, but then they wanted me to go to some app store and install something else. They said it’s their app. I’m confused.”

Today’s users generally know web when they see it. I have the greatest laughs with them. To understand what I mean, and appreciate the PWA (Progressive Web App) installation process, show it to a non-techy user, and wait for the cutest “um.. [conspicuously looks at you] was that it??” reaction.

We have Google to thank for the efforts they made for us and our users in this regard. Still, the one thing that’s always going to matter more is what’s inside.

Delightful is possible. 60 fps is possible. All the Olympic gymnastics that these views do, as well as being fun, aim to help the user understand what is happening. Where everything went, and where everything came from. But as lovely as they are, they weigh on our heads with their need for complex state management. Look at this beauty:

This is my favorite piece of interaction. It couldn’t be any more seamless for the user. Yet behind the scenes, seemingly unrelated contexts are doing some elegant communication to accomplish this goal. While untrue for OO (Object Oriented) systems, here any view element has access to any piece of app state without ANY consequence. I’ll wait here till it sinks in.

We don’t need to call for an external state, and we don’t need to wait for it. It’s because of the nature of the system. It’s because of how the whole app state is a single bag of data that is available everywhere. And because the state is immutable, only contexts with explicit requirements to update their contextual sub-bags of data are able to do so. What a sentence.

In this example, the developer designs the map state and implements the pan based on location state updating. The jolly fun happens when in the context of experience creating wizard, all the next developer needs to do is:

I mean, I could’ve used words to explain this, but look at it. That’s English.

Notice how currMapCenter is there for the taking. It requires no special strategy of how to React™ when there are new map center coordinates. They are just.. there.

Not only does it make solving this use-case a joke, but the data guarantees that come prepackaged with the immutability allow us to not worry about manipulating the map state outside of it’s context. And what do we call development without worries?

Thats joy, my invisible-bug-squashing friends.

Joy!

I haven’t mentioned that we use Elm yet, have I? Sorry bout that. Well, I run this small team that somehow, after Elm, became a lot bigger, even tho the number of people remained. We can’t pass the free plan on Sentry. We don’t have any testing work left for our family members either. And we ship features like алва[1]. So pardon me when I assume that EVERYONE is on the Elm train or getting there.

Look, I don’t know how much this matters to you, as no number measures user’s delight, but let’s see anyway:

Just a little something that comes as a bonus with Elm builds.

Consider how this app, with it’s 37K lines of Elm, and it’s 280KB gzipped size, 40% of which are libraries, generally has a first load in 4 seconds. I have no idea when the hell would I ever need to even think about splitting and loading modules lazily. Something that is imperative with the other platforms.

Dark story time: last year we were working on an Angular 2 project. Started with the early betas. When we completed it, NG was stable, but it took the app 20 seconds to start. It was because it needed to compile the views on the device on every start. First, it took us time to realize that. Then, we had to wait for the ahead of time compiler to get released before we released the app. As I said, a dark story. Go play it with friends. Start with: “A product launch got delayed”. [2]

I believe you can feel my relief when in the first run of this test we got
100, 98, 98. We then enabled long-term caching and.. well you see the hundreds.

I am keeping distance from implementation details throughout this article because in the end, this is what matters. This feeling that I have.. it’s.. let me try it this way: have you been noticing how popular it is for a front-end guy to feel stressed out? How much effort needs to be invested to be on top of the game? Has there ever been a bigger tools and techniques explosion compared to what’s happening now on the front-end? As self-abusive as it sounds, If I didn’t actually love this craze, I wouldn’t have discovered functional reactive programming. I wouldn’t have discovered Elm. [3]

I finally live in a world where technicalities are irrelevant. For any challenge there is an obvious approach to solving it. I’m just focused on what I love the most: fading and blurring and moving things around.

Not only do I not suffer the impostor syndrome anymore, but I feel something that rests comfortably on the opposite side on that spectrum. Ever since the days I started following Elm, every time I see a massive new feature roll-out in any of the popular frameworks or tools, I usually think: “Oh look, another idea taken from Elm.”, either Redux or immutability or stateless view components. Or even better, I realize that it’s a solution to a problem that is nonexistent in Elm Town.

I want you to realize the advantage Elm gives you. They can go nutz in trying to improve JS. But they’ll never be able to fix it unless they change it. And you know that I know that you know that they cannot do that. So instead of endlessly learning how to build stuff, you’ll start building stuff, endlessly. Pulitzer please!

Elm is totally new and different. It couldn’t be this good any other way. The hardest thing you’ll have to do is unlearn all the OO patterns you use to handle problems that are (together!) nonexistent in Elm. Seriously.

Have you started using underscore to transform data? Have you been moving away from classes and use modules as encapsulation contexts? These are great first steps that would ease you in into the productivity boost in Elm’s pure functional world.

But, if you are already using React or Angular in a functional reactive way, you’ll find that Elm is where everybody got their ideas from and how they look like in their purest form. You alone will be able to replace 20 of the you before you became Elm.

Here’s the hard question: Who’s gonna help you once you get stuck? I know this is what you are afraid of. It’s a small community, so the support is questionable. How do I put this.. you will nowhere find more dedicated and more capable group of people in one room. I don’t know how they breathe in there! Everyone trying to beat everyone else for who gets to help the newcomer first!

He fights about everything with everybody.But when you ask something on Slack, chances are, he’ll be there to help you.

And then get this, there is a weekly thing called “No dumb questions” on Reddit. What? They didn’t use that name?? Oh well..

So what was I saying.. oh yes, delight users with PWA, enjoy doing so with Elm. And if you absolutely need to be present on the app stores, for extra 5% effort, Cordova will take you there. We spent the extra time because one of the core features of Dscova is notifying users as they move around when something awesome is nearby. And since background geolocation is still not conceptualized for the Web, we did it in the hybrid versions. That, and the fact that Apple doesn’t love Safari the way Google loves Chrome.

Let’s start wrapping up. This is too much not writing Elm for me.

Resources: When we were following beginner material, these were the greatest ones:

• Book: Elm in Action by Richard Feldman (a great great guy. just. great.)
• Video course: Elm for Beginners by James Moore
• Video course: Building Web Apps with Elm by The Pragmatic Studio
• Go make some noise on Slack
• Listen to our spiritual leader on Elm Town
• I wanna put a special note here for the folks who like me, when I was starting, want to begin on a production app right away. Go learn Webpack. We were used to Gulp chains, but now our build process is nice and tight thanks to the great tools that exist for Webpack.

Hold the applause fellas, special props are coming:

_The [Somebody](https://github.com/pdamoc" rel="noopener" target="blank" title=") from the Elm community that I really hope you find for yourself.

The kind of guy that holds your hand and helps you cross the road.

_The [associate](https://twitter.com/trajches" rel="noopener" target="blank" title=") you can dream of.

The only guy who could ever outwork me.

_[Some dude](https://github.com/evancz" rel="noopener" target="blank" title=") that is too smart for his own good.

And because of it, he now has to fight every other smart person who knows which direction Elm should take.

[1] Something that my country used to ship a lot.
[2] Angular is solid today. The AOT compiler can easily be plugged in your Webpack config, or even simpler, you might just wanna use their CLI.
[3] Elm is actually not a reactive platform anymore. It became something way more intuitive than that.